[BLOG] Yes we shouldn't! The WHY of C# 4.0
Eric Lippert, a designer and developer on the Microsoft C# .NET team, has written a series of interesting blogs on the future of C#. They typically discuss features that are in for C# 4.0, but his latest entry takes a slightly different tact and instead focuses on the why rather than the what.
Thus far, updates to the C# language have typically been major changes to the entire paradigm of programming in C#: generics / templated code, compiler-generated iterator classes, additional abstract language constructs, enhancements to strongly-typed interoperability, extension methods, partial classes, partial methods, lambdas, type inference, language-integrated queries, and the list just goes on and on.
While these broad paradigm shifts have helped to make C# one of the most powerful and exciting languages to work with, they have also brought about some complaints from developers who simply cannot keep up with the myriad new features or do not care to. Some people have given voice to the feeling that they are tired of having the rug pulled out from under them, and perhaps with good reason.
In this latest article, Eric talks about these complaints and how they influenced the feature selection process for C# .NET 3.5 and the soon to be released C# 4.0. C# 3.5 was limited to language-integrated queries (LINQ) and some supporting language features, like the var declarative type inferential. Almost nothing else made the cut. C# 4.0 will be limited quite strictly to the dynamic language runtime (DLR) and dynamic type interoperability between C# and other languages. In addition, we get generic covariance finally!
Basically, versions 3.5 and 4.0 are more focused in their feature sets. They lack the broad reach of the prior two major versions, which more or less Changed the World®. Not to be confused with Breaking the World®; my personal specialty.
This raises an interesting point about change in general, but quite specifically, change as it relates to software development and my perspective.
I tend to be someone who doesn't just appreciate new features and changes; I crave them. I enjoy learning, enjoy additional flexibility and enjoy powerful new language constructs. It never really occurred to me that other developers don't always appreciate these alterations of a platform they are already familiar with. These paradigm shifts, if you will.
It made me think about some of my own projects and the approach I take.
My company ships products that are used on touchscreens to control complicated machinery. Our software is often used by people who are not even computer literate, so I am intimately familiar with the notion that some users simply cannot deal with change. They learn how to do something one way and that's that. No matter what you do to try to improve their experience, you will meet with resistance just for the fact that you've forced them to rethink or relearn the way they were doing something. At the end of the day, most of our customers just want to run their football field-sized printing press and be done with the software altogether.
It never really occurred to me that software developers, a relatively advanced end user base, would share this attitude on some level. I generally think of this phenomenon as being unique to situations where the end user base is ignorant of computers and software, but Eric's blog points out that this is completely, basely, utterly false.
The bottom line is that end users are cantankerous. They dislike changes that don't clearly benefit them but do cause them to relearn or rethink, and even software developers can suffer from this anti-change mentality.
"Don't fix what ain't broke."
Will this make me significantly alter the way I approach software development? Probably not. I enjoy my maverick status as the guy who will tear apart anything, touch hundreds of files and not bat an eye when the commit takes minutes instead of seconds. I fill a needed role in any software development group, and I'm comfortable in that role. I am the guy that embraces new technology, pushes for change and takes the brunt of the abuse if and when that change is ill received. It's all good; it is often ill received but later appreciated, and that's precisely why I take the approach that I do. There are plenty of people who are more cautious than I am to keep me in check.
That said, it is something to think about. The situation I face with my end users is not solely due to their relatively basic knowledge of computers and software. Microsoft faces the exact same problems with their audience of developers!
Here is what I take away from this: No matter how primitive or advanced your user base is, the bottom line is that all people dislike software changes that they view as unnecessary -- and everybody has their own notion of what is and isn't necessary.
Some people will always want things to stay just the way they are. The art is finding a happy medium between sweeping change and stagnation.
Thus far, updates to the C# language have typically been major changes to the entire paradigm of programming in C#: generics / templated code, compiler-generated iterator classes, additional abstract language constructs, enhancements to strongly-typed interoperability, extension methods, partial classes, partial methods, lambdas, type inference, language-integrated queries, and the list just goes on and on.
While these broad paradigm shifts have helped to make C# one of the most powerful and exciting languages to work with, they have also brought about some complaints from developers who simply cannot keep up with the myriad new features or do not care to. Some people have given voice to the feeling that they are tired of having the rug pulled out from under them, and perhaps with good reason.
In this latest article, Eric talks about these complaints and how they influenced the feature selection process for C# .NET 3.5 and the soon to be released C# 4.0. C# 3.5 was limited to language-integrated queries (LINQ) and some supporting language features, like the var declarative type inferential. Almost nothing else made the cut. C# 4.0 will be limited quite strictly to the dynamic language runtime (DLR) and dynamic type interoperability between C# and other languages. In addition, we get generic covariance finally!
Basically, versions 3.5 and 4.0 are more focused in their feature sets. They lack the broad reach of the prior two major versions, which more or less Changed the World®. Not to be confused with Breaking the World®; my personal specialty.
This raises an interesting point about change in general, but quite specifically, change as it relates to software development and my perspective.
I tend to be someone who doesn't just appreciate new features and changes; I crave them. I enjoy learning, enjoy additional flexibility and enjoy powerful new language constructs. It never really occurred to me that other developers don't always appreciate these alterations of a platform they are already familiar with. These paradigm shifts, if you will.
It made me think about some of my own projects and the approach I take.
My company ships products that are used on touchscreens to control complicated machinery. Our software is often used by people who are not even computer literate, so I am intimately familiar with the notion that some users simply cannot deal with change. They learn how to do something one way and that's that. No matter what you do to try to improve their experience, you will meet with resistance just for the fact that you've forced them to rethink or relearn the way they were doing something. At the end of the day, most of our customers just want to run their football field-sized printing press and be done with the software altogether.
It never really occurred to me that software developers, a relatively advanced end user base, would share this attitude on some level. I generally think of this phenomenon as being unique to situations where the end user base is ignorant of computers and software, but Eric's blog points out that this is completely, basely, utterly false.
The bottom line is that end users are cantankerous. They dislike changes that don't clearly benefit them but do cause them to relearn or rethink, and even software developers can suffer from this anti-change mentality.
"Don't fix what ain't broke."
Will this make me significantly alter the way I approach software development? Probably not. I enjoy my maverick status as the guy who will tear apart anything, touch hundreds of files and not bat an eye when the commit takes minutes instead of seconds. I fill a needed role in any software development group, and I'm comfortable in that role. I am the guy that embraces new technology, pushes for change and takes the brunt of the abuse if and when that change is ill received. It's all good; it is often ill received but later appreciated, and that's precisely why I take the approach that I do. There are plenty of people who are more cautious than I am to keep me in check.
That said, it is something to think about. The situation I face with my end users is not solely due to their relatively basic knowledge of computers and software. Microsoft faces the exact same problems with their audience of developers!
Here is what I take away from this: No matter how primitive or advanced your user base is, the bottom line is that all people dislike software changes that they view as unnecessary -- and everybody has their own notion of what is and isn't necessary.
Some people will always want things to stay just the way they are. The art is finding a happy medium between sweeping change and stagnation.
0
Comments
Having moved over to VB.NET, I miss some of the things you could do with C# (especially considering my Java/C++ background). That said, I think Microsoft is doing a fine job with the two languages and is making some very interesting changes to the .NET framework in general.
I am someone who is of the mind that most of the changes to C# have been necessary, all the changes have been helpful and welcome, and on the whole, I think they've done a great job of finding that happy medium between change and stagnation that I mentioned in the closing sentence of the blog. I really enjoy working in C#, and looking ahead to C# 4.0 and beyond, it seems to only be getting better.
I think C# need to continue to evolve, only because i can now do things that would have take 100 lines of codes in 3 class in one class with 40 lines of code. For us programmer who do new products every years that kind of change means we save a lot of time, and a lot of dump paste/copy/change.