I hear many things about my favorite programming language these days. Not all are favorable. Some statements conflict. There are a couple of facts about the latest edition (additions) to C# that cannot be denied.
1. Anders has added in support for dynamic language interop. This is mostly a matter of implementing a new static type whose static type is dynamic. I guess that is the C# way to do it. Basically, a declaration of 'dynamic X;' means we will obtain a boxed object with some metadata attached to it to let us know what type it really is. This is almost like generics in Java. The performance penalty is not too terrible at run time when all factors are considered. Still, there will be a penalty. This won't be high performance. Worse, there is no question that this is full-bore late-binding. In any late binding situation, you loose type safety. No compiler can ever predict that any piece of late-bound code will ever work, or work in all scenarios. The compiler will go along with it, presuming that you know what you are doing. When the build is successful, do not presume that the compiler has endorsed your code.
2. Anders has added support for optional parameters, so we can now have pain-free use of C# in connection with the dreadful, much-detested, out-dated, out-modded Microsoft Office object model. Optional params are big in OLE2 or COM or ActiveX or whatever you want to call that disgusting old shit we used to do. Lamentably, the dastardly Microsoft Office object model is still a filthy COM beast. You should obtain less painful interops with all COM servers because of Anders most recent additions to C#4. Still... this is a dirty thing to accommodate. It is the programming equivalent of saying "have sex with HIV infected individuals, just use this condom".
3. There is also some stuff about co & contra-variance with greater safety. I have never stubbed my toe on Co & Contra Variance, so I see no issues solved here. I suppose this helps in a few marginal edge cases. I know of none in my code.
4. Finally, Anders & co are re-writing the C# 4.0 compiler in C# itself, thus making the compiler available as just another managed code software services at run time. The presumption is that C# 4.0 programmers will now use this handy-dandy, ever-ready compiler to engage in meta-programming techniques and tactics. Once upon a time, this was the exclusive privilege of people coded with Interpreters. Java programmers can only get access to this sort of dynamism through a jar library called Janino.
These last two items are of no consequence to guys like me. Some may be jumping for joy, but I don't need a runtime compilers just now.
Surprisingly, the announcement of these language features has tripped off a debate surrounding the question of whether C# is getting too big for it's britches. Some say that C# is becoming an over-bloated Swiss Army knife. I really think this debate misses the point entirely. The issue is not one of whether the language is getting too big, but rather whether it is growing in the wrong direction.
Certainly, I do not welcome the advent of the dynamic type. I don't need it, and I don't plan to use it. I suspect that the mere presence of this type will slow the compiler considerably. I hope it doesn't result in generally fatter CIL for all, which would in turn lead to fatter X86 code.
I am not a fan of optional parameters. Optional parameters are element & aspect of a generally sloppy approach to programming. That is why they are in VB. They are not unlike the unstructured goto statement. They are just bad for your code. Either a param is necessary or it is not. If it is necessary, it should always be required, and it should always be set. Programmers should not be allowed to 'safely' ignore a parameter. This is one of the many ways in which unexpected and somewhat unpredictable behavior emerges in a system. Programmers should be aware of the change in behavior flag settings will produce. Of course, I realize that Optional Parameters were big in the days of COM. This is one of several reasons why COM was a dirty, fifthly, nasty, ugly, disgusting, detestable, nasty, wretched, leaky, buggy, unstable, evil piece of shit. [Did I mention that COM had no security model and was single handedly responsible for the Great Spyware Pestilence of 2003?] There are explicit reasons why we flushed COM down the toilet in .NET. One of the reasons optional params were rejected in C# is that we wanted to rid ourselves of this corruption. Now here we go again. Not good.
I understand why Anders reversed himself. Many, many, many C# programmers have been bitching for years about how difficult it is to drive the Microsoft Office Model because C# does not support optional params. Anders caved in under pressure from customers and the high command. In a very real sense, I know this will make my life easier when I must do an Office automation project. Still, I do not look forward to fully managed C# library, with no element of COM, which show optional params all over the place. This eventuality will signal the arrival of sloppy coding techniques in the rather purist world of C#.
My real bitch is that the two language features we really need the most did not make it into C# 4.0. What are those features?
1. Traits, just like in Scala
2. XML literals just like in VB.NET
In all honesty, these are the only two linguistic innovations I have seen in the past 6 ot 7 years that did not originate in the C# project.
Traits are basically implemented Interfaces which you can tack on to almost any object. They give you the advantages of interfaces with the advantages of mixins in Ruby. The final yield is a language feature which gives you the reliability of single inheritance with some of the advantages of multiple-inheritance.
XML literals threw me for a complete loop. XML literals took VB, a language which was dying IMHO, and suddenly made it the best language for the MVC framework. You don't know how much it hurts me to say this, but I would never want to code a helper class in MVC without the aid of VB.NET XML literals. This is not to mention all of the complex XML transforms which this system makes incredibly easy.
XML literals are probably the greatest, most practical, most useful idea I have encountered in the past 5 years. The biggest thing since Generics. Scala also has a form of XML literals, but they don't seem backed by the sort of library power VB.NET offers. In any case, C# should have had this feature. Omitting XML literals from C# 4.0 is the same thing as capitulating the MVC framework to VB.NET. Anders needs to take notice of this fact and make some corrections.
So the final verdict is clear. C# is not guilty of getting too big. C# is guilty of expanding in the wrong direction. C# is guilt of not expanding in the right direction. All-in-all I am quite disappointed.
