The Follies of C# 4.0

Nikhil Kothari has been blogging furiously about Visual Studio 2010 and C# 4.0.  One of his posts covering the dynamic programming features in C# 4.0 raised some interesting discussion in the comments.

Some like Francois Ward:

I heavily dislike this. My philosophy has always been “right tool for the right job”. There are dynamic languages that are vastly superior to C#, if you want dynamic. C# was meant to be a “pure” language, to do the stuff where you want as much strong typing as possible (also the reason behind Spec#), and as clean as possible.

This defeats that purpose in such a way that only an FxCop rule or code reviews could stop it from ruinning a codebase. If I wanted dynamic, I could do it in IronRuby (once thats fully out), and call the result from C#.

More so: this dynamic feature was mostly meant to help with COM interop, not as a convenience to save a few lines of code… and people are -already- thinking of ways to misuse it… Really, the .NET runtime was made so we could have all the languages we want on it, EXACTLY so we wouldn’t need a “one language to rule them all” thing… The best codebases would use C# as the core, IronRuby (or something similar) for places where you need Dynamic, and F# for places where you need functional… there’s no need to stick C# everywhere…and thus, there’s no need to add this to C#. Its too late now, but at the very least we can make sure its not abused.

And some like poster “HB”:

Why such resistance to this? Mandate to your team not to use it if you don’t like it.

Every release of every programming language has the same problem. People resist the new features claiming that they will be abused and ruin everything and yet here we are in C# 4.0 and the use of ‘var’, anonymous <fill in the blank> and other C# 3.0 features haven’t destroyed us.

For people that use a lot of Json (like in MVC), this will be especially handy

I tend to agree with Francois Ward.  While I appreciate the changes in C# 2.0 and 3.0 (moreso 2.0 than 3.0), this transition from “C# pure” to “C# bit-o-everything” is a bit disconcerting; it feels like change for the sake of change and it feels like change in the wrong direction.  As a disclaimer, JavaScript is perhaps my favorite programming language – I love how fluid the language is.  But on the other hand, I can also appreciate some of the structural rigidity of statically typed languages like C# in helping to coerce good OOP practices.

As many have made the argument “Well, you don’t have to use it!”, I’d like to respond from this angle. It’s not a matter of whether I or any of us personally use it but rather how your stereotypical RAD developer (still the majority) uses it or rather abuses it.

I personally think that McConnell gets it right in Code Complete:

“The computer doesn’t care whether your code is readable. It’s better at reading binary machine instructions than it is at reading high-level-language statements. You write readable code because it helps other people to read your code.”

“Making code readable is not an optional part of the development process, and favoring write-time convenience over read-time convenience is a false economy. You should go to the effort of writing good code, which you can do once, rather than the effort of reading bad code, which you’d have to do again and again”

In other words, programming in such a way as to reduce your LOC for a particular operation, while increasing the density (amount of logic in a given number of lines, words, or whatever other metric) or complexity of the statement has a negative effect on readability of the code (at least until the practices become standardized and fairly well understood). The problem I foresee with C# 4.0 is that it introduces features which will not be generally understood across the spectrum of developers. Remember: you are never writing code for yourself, you are writing code for your customers, you clients, the people who will maintain the code after your, your peers whom you work with, consultants who may not understand lambdas, and so on. You may have junior developers on your team (or even senior developers on your team) who may not be able to grasp your idea if you entwine your implementation with cool nifty tricks to reduce LOC.

From a practicality perspective — as much as this sucks, it is always safer to program to the lowest common denominator; assume that you are writing your code for a novice to maintain and your code will be more legible, the structures will be easier to understand, and the comments will be less terse. Use patterns that are simple to understand. Use statements which are easy to read for a novice as a novice may one day be maintaining your code or extending it. For those reasons, I think that this is a mistake…a terrible mistake to satisfy a set of fringe developers who will actually “get” it and use these constructs in the proper manner.

The forward evolution of the C# language, while it does contain some awesome features and looks more and more like native JavaScript with each iteration, continues to confound me with the lack of concern for the general development community. Instead of focusing on constructs and framework extensions which promote design pattern usage, domain models, and good practices, we get extensions and constructs which undercut the effort to increase the development IQ of your average developer

It WILL be abused and then people like myself will have to go in there and try to untangle the intent of developers who misuse these facilities provided to them for all the wrong reasons just as I’ve seen people abuse System.Linq instead of writing good, performant code.

Microsoft’s C# Future page is a good place to start with regards to some of the features coming out for C# 4.0.