2 February 2009
New features in C# 3.0 and C# 4.0 – are Microsoft undermining C#?
I have noticed a number of features creeping in to C# 3.0 and the forthcoming C# 4.0 that I feel very uncomfortable with. In their desire to continue to develop and enhance their platform, could Microsoft be in danger of undermining C#?
Many of the new features in C# 3.0 provide little more than “short-cuts” for developers at best. At worst they can lead to unreadable code and bad programming practices.
What benefit do Auto-implemented properties bring any benefits other than saving a developer from writing a couple of extra lines of code? Object Initializers are a similar case in point – why undermine the use of the constructor by providing a short-hand means of invoking objects? Are these really improvements, or a license for lazy programmers to write unreadable code?
The features being proposed in C# 4.0 are taking things further as Microsoft appears to be trying to create more common ground between C# and it’s ugly sister Visual Basic.
The planned introduction of dynamic lookup allows for the declaration of objects that are assumed by the compiler to be able to support any operation. This is being achieved by adding a new API to .NET 4.0 – the Dynamic Language Runtime (DLR) – which will allow for the introduction of dynamic programming languages on .NET. For C# developers it is, in very simple terms, a way of switching off static type-checking.
This is pretty dangerous stuff as attempts to call unsupported methods on dynamic objects will only throw exceptions at run-time. Perhaps I am getting old and inflexible, but dynamic lookup strikes me as a license to write unstable code. Any flexibility afforded by the dynamic lookup is surely outweighed by the potential maintenance and support headache caused by difficult to track run-time errors.
Dynamic lookup has been available to VB programmers for some time in the form of late-binding. Although strict type checking may be an inconvenience at times and require more code, my experience of writing and maintaining VB and C# code has taught me that time spent in good code design is always time saved in long-term effort.
Microsoft are also introducing optional parameters into C# 4.0 – another feature that has long been available to VB developers. I’ve never understood the need for optional parameters and have regarded them as a short cut for lazy developers. After all, they don’t offer anything that can’t be achieved through method overloading.
My understanding of the rationale for introducing optional parameters is that they will help to make life easier for Office programmers who have to cope with method calls that can contain up to thirty parameters, most of them optional. That said, I would have thought that better class design of the Office API would be preferable to introducing unnecessary language features.
Part of Microsoft’s rationale for many of the changes C# 4.0 has been to achieve closer parity between VB and C# – “for the benefit of everyone”.
Visual Basic has fallen a long way since it was the language of choice for rapid application development on the Windows platform back in the days of COM. It was fatally undermined by the introduction of C#, which allowed for rapid development within a more rigorous object-orientated language. Since Microsoft removed extended support for Visual Basic 6.0 in March 2006, more and more legacy systems have been ported away from VB.
As a Visual Basic veteran who jumped ship to C# in the early days of the .NET framework, they key benefit for me was the ability to write more structured and disciplined code. More importantly, I could be assured that everybody else in the team was doing this too. It would be a shame to see this undermined and see a rise in erratic code written with C#.