Who says VB is not for grown-ups?

I am returning to a theme I have touched on before – my fascination for the intrinsic design and mechanics of languages and the sheer quality and care being put into Visual Basic by the language development team at Microsoft. It does not matter how much the idiots at the top of Microsoft annoy us, you have to acknowledge that their tool builders are top rank.

I was looking at Paul Vick’s blog and reviewing progress on some of the VB.NET language elements. Orcas is going to include a replacement for IIF – and guess what – it is If - but implemented as a true ternary operator. In true Visual Basic style it allows the two possible return values to have different types although it will only return the “wider” of the two. Thus, if your If statement was something like:

myVal = If(<some condition>, <integer value>, <long value>)

then the returned type will be a long in both instances. If the return types are completely incompatible then an error would be generated. Look out for If statements with function brackets in the Orcas Beta2.

We will also see hash tables that support multiple keys – just what I was looking for the other day to solve a little problem – but I had to take another longer route to a solution instead. This allows the quick storage and retrieval of data accessed by multiple keys simple and straightforward – hash tables were long overdue in Classic VB and it is great to see them continuing to develop now they are available to us in VB.NET

Paul also discusses the issue of anonymous types ** and how the C#9 team have decided to make them immutable. However, with an eye on the upcoming Dynamic Language Runtime (DLR) the VB team look likely to take the opposite line and that brings me on to the often argued differences between C# and VB.NET. I have previously taken the line that the differences between the two languages are immaterial and that if you want to program to the .NET framework then you should just choose the syntax style that you prefer (taking into account that C# programmers seem to get paid more). That C# developers attract higher salaries is odd at a functional level (and probably just reflects the language choices of higher paying organisations) as C# developers are always going to be less productive than a VB developer of similar experience and skill. C# developers will immediately start squealing about the supposed verbosity of the Visual Basic language and even site the supposedly poor aesthetics of the code on a screen but when you factor in the broader language and class library coverage with magnificent support from the IDE then it is clear that VB is a winner in terms of productivity.

There is another angle though and this is one where the generally perceived wisdom might just be “upside down”. Jeff Atwood at Coding Horror was on the case the other day in a post titled “C# and the compilation tax”. He was trying to balance the two languages – on the one hand C# seems to have become the “language of choice” (the de facto standard) for .NET and yet you have to accept the massive drain on productivity that is the very limited IDE support for C# compared to VB. On many .NET support sites (particularly those hosted by Microsoft) you will often find demonstration code written in VB but with a slightly snide or snobish comment that this is because C# programmers can probably decipher the VB syntax and yet somehow VB programmers can’t manage with C# examples. I think that Jeff’s view is that advanced code available on the net is going to all be in C# so you had better “suck up” the productivity overhead and not just learn C# but convert to it. I beg to differ.

If I were to sit back in my old IT manager’s chair (phew it was a good while back when I still wore a suite) and review the C#/VB choice then I might conclude from the evidence that Visual Basic was (superficially at least) simpler code to understand – and that would give me a code maintenance edge. Plus it would appear that VB is faster to write – almost slam dunk! Now about the issue of “the community” and it’s apparent fixation on C#. Is it true that C# is hard to understand if you are not a C# programmer – is there too much “cognitive friction” (as Jeff Atwood would have it) in writing one language while trying to read and understand code written in the other?

Certainly the syntax could appear stark – well unless you are used to writing JavaScript of course. So there is no syntactical dissonance for the large army of developers who are targeting the web as a software product platform. For the rest, well I am of the view that a couple of hours with a simple C# primer would cover most of the ground – quickly making sense of things like:

for(aLoop=0;aLoop<24;aloop++) style="color: rgb(51, 204, 0);"> \\some stuff
}

and the way that variables are declared:

bool upDown = false;

I can see that the closing brace is a poor substitute for a proper block closing statement (like “End Select”) but with proper indentation it is just not that hard.

C# interacts with most of the classes found in the .NET Framework in just the same way as VB.NET – it is just that Visual Basic is “richer” in terms of language elements and pre-defined support classes – so that makes C# smaller and simpler to understand doesn’t it?

There are a few potential “gotchas” around – say in the differences between the way a VB “Select Case” statement executes and the way that a C# switch statement runs but none of this is difficult to understand. Plus if you are just reading C# the issue of the benighted case sensitivity hardly arises – all in all I think that C# code is very accessible to the VB developer. It just takes a (very) little effort.

Visual Basic to author new Languages

Paul Vick also beat me to a comment on a throwaway line from Miguel de Icaza when he was describing work on the Mono version of the DLR that the new Microsoft JavaScript compiler for the DLR was written in Visual Basic. We already know that the Mono version of the Visual basic compiler was written in Visual Basic but it is good to see that the language is being correctly treated as a first class language at Microsoft as well. Paul also added that version ten of VB (currently dubbed VBx) will be written in VB as well.

** Anonymous Types
Anonymous types – what are they and why would I care?

Anonymous types are an essential by-product of the LINQ feature of the .NET languages and will prove very useful indeed as they enable developers to define types within code, without having to explicitly define a formal class declaration of the type. Developers will be able to “crack on” with the code and leave it up to the compiler to fill in the gaps.

Why should you care? Well I think that we all need to put some effort into understanding the structure and function of our languages as we face up to a multi-processor future. I was reminded of this during the week when we were working up a custom thread pool to service incoming asynchronous data on the Windows Mobile platform. The challenge was to manage the inflow of data in a manner that maximised the number of data items processed while ensuring that the program UI continued to perform at a level that would meet user expectations – plus it had to run on a wide variety of hardware devices with varying resources and processor speeds. If you do not understand your language, runtime and (to an extent) the hardware then you just can’t solve problems close to a system’s capacity. In a multi-processor future, a lot of individual process threads are likely to be approaching and reaching the capacity of a given device resource.