August 2006 – Page 4

I’ve spoken with several experienced developers in recent weeks, discussing whether the .NET framework’s two main languages, C# and VB.NET, are in danger of becoming too complex for the ‘average’ programmer, or indeed for the average programming task (whatever that might be). While you could argue that complexity is necessary to model complex problems and domains, the continuing abstraction of programming languages does not provide much support for this view. A complex, general purpose programming language will rarely be a good substitute for a domain specific language (generalisation versus specialisation).

Maybe I’m just getting old and my shrinking brain can’t handle all this complexity, but deep down I feel that code should read like prose. I do not want to waste valuable time trying to figure out what a chunk of code is trying to do, it should be apparent almost immediately. Is this unrealistic? Possibly, but the driving force behind the evolution of computer languages has always been to simplify and increasingly shield programmers from the low level implementation details so that they can concentrate on solving higher level business problems.

I have programmed in C/C++ for over 20 years. When I first encountered VB in 92-93, my first thought was that it was a ‘toy’ language designed for non-programmers to write quick and dirty GUI applications. I could not have been more wrong. I did not have the maturity at that time to realise what it represented and its possibilities. It has had a profound effect on the software industry not only in terms of what could be achieved quickly but it also raising the expectations of what could be achieved quickly! VB’s obvious attraction and strength was that it empowered less experienced programmers to achieve results that were previously only within the reach of ‘guru’ programmers. Of course, you still had to delve into the Win32 API to get at some of the more ‘advanced’ features (exemplified by Dan Appleman’s work in this area ).

What made VB so attractive was that it was simpler and much more productive than coding in C/C++. If VB.NET and C# both increase in complexity, is there a reason for having two languages that serve the same purpose? As C# and VB.NET evolve further, will a single generic .NET framework language emerge, or will a ‘new VB’ diverge from C#?
In this terse example on anonymous delegates from Developing for Developers “…, here’s two lines of code that produce a list of all files larger than a given size in a given directory”, it is not immediately obvious what is being performed inside the method even with the previous description (BTW that post at Developing for Developers provides a good introduction to anonymous delegates):

static List<string> GetBigFiles(string directory, int bigLength)

{

List<string> filePaths = new List<string>(Directory.GetFiles(directory));

return filePaths.ConvertAll(File.OpenRead)

.FindAll( delegate(FileStream f){ return f.Length >= bigLength; } )

.ConvertAll<string>( delegate(FileStream f){ return f.Name; } );

}

OK, this is a hand-picked, contrived example and not even the most efficient way to accomplish this. You could break this down into separate lines, but the point is the language is enabling, perhaps even encouraging us to write hard to understand (and therefore maintain) code. This reminds me a little of ‘dense’ C code! [In fact, this issue has recently been addressed in C# 3.0 using Lambda Expressions…]

You could argue that less experienced programmers will simply not use the new, more complex features of the language(s), but experience would suggest otherwise.

Please don’t misunderstand me: these powerful language features obviously have their uses. I’m just intrigued about the direction these two languages are taking. With power comes complexity, and with it also the possibility of subtle, hard to understand bugs.

Is there a need for a ‘new VB’?

Bruce Schneier’s Security Blog

Are C# and VB.NET in Danger of Becoming too Complex for the Average Programmer?

Does .NET Rock?