A language for all seasons

I find programming languages are at least as interesting as the applications we build using them. Part of the reason I find JavaScript so fascinating is its idiosyncratic but oh so effective approach to so many of the challenges facing any language developer. As a Visual basic classic user from the earliest versions it was great watching the language itself develop although I always got the feeling that the team responsible for Visual Basic within Microsoft never quite “got” how it was being used by the development community at large. The first version of VB.NET rather confirmed that feeling – it was a mess that failed to meet the need at so many levels I am certainly not going to attempt to list them. However, things got better and the current iteration of VB.NET is an excellent development language for a very wide range of applications. It is also clear that the Visual Basic team at Microsoft care about the language and about how it is applied. The Visual Basic IDE and language are now quite close to reclaiming the RAD (rapid application development) label lost in the confusion as VB migrated to the .NET platform. It is also great to watch the VB team continue to extend the language into new areas making VB.NET one of the “hottest” languages around.

Don’t believe me, then take a look at the series on closures (lambda expressions) on the VB team blog written by Jared parsons. A year ago I posted some notes on the use of closures in JavaScript and I for one am looking forward to having lambda expressions in Visual Basic and (by implication) the facility to treat functions as first class objects.

It looks as though Visual Basic is in for some interesting times. I am not just talking about the new language features, welcome though they are, but also about the approach that VB has to data typing. If you want, you can bolt your VB app right down when it comes to data types and implement a very strict typing regime. Alternately, you can take advantage of VB’s liberal nature and allow the automated casting of data types and take advantage of “late binding” to simplify your code – at a very moderate performance penalty. The reason I raise this is the fascinating challenge of the Dynamic Language Runtime (DLR) and the choice of VB as one of the prime scripting languages for the Silverlight project.

We have had VBScript around for a long time and VBA is arguable yet another scripted form of VB. VBSCript was the foundation of Classic ASP, popped up as a development tool for those building applications for the Windows CE (now Windows Mobile) platform and (of course) runs as a scripting language on Microsoft Operating systems. Heavens, there was even client browser support in Internet Explorer although here it lost heavily to JScript. But the days of Classic VBScript are probably coming to a close as a new scripting version of Visual Basic running against the .NET Framework comes to the fore. I love the idea of being able to run a loosely typed Visual Basic scripting edition in an environment where it will be able to co-operate with a strictly typed version of itself running against the CLR. However, things are expected to develop from there. The next version of Visual Basic (the one after VB9/Orcas) currently dubbed VBx looks likely to straddle both worlds – a language for all seasons capable of running seamlessly against both the CLR and the DLR.