I did not think I would ever do this but

I have translated some VB Classic code to VB.NET. I have always promoted the line that VB Classic applications should not be translated into VB.NET but should be redeveloped from scratch to take full advantage of the .NET Framework.

I needed to quickly move some existing VB6 functionality at a customer site into a Windows Service as the process needed to be run automatically to a regular time schedule and that was not happening reliably enough. I had a choice I suppose – I could have pasted the VB6 code into a new project that was compiled as a VB Classic DLL and then called the resulting COM object from my service. But then I though – how hard can it be? OK, the code reads data from MS Access databases, uses User Defined Types and even has a GoSub or two – but the two approaches looked likely to have similar time overheads and it is always interesting to try something new.

How did it go? Took a couple of hours – the MS Access database connections were still handled by DAO as I needed to support client side code to handle data locks within a very active set of databases. The User Defined types translated seamlessly into Structures and a little tidying sorted out the code structure. A combination of “My.Settings/app.config” and an editable XML file dealt with things like environment variables and INI files (yes this app went back a long way). And then I had a think about the number of changes I had made and the fact that my long experience with .NET had made those changes both predictable and straightforward. I wondered just how I would have coped if this exercise had been my first experience of VB.NET. This was not a hard task but the sheer number of seemingly meaningless error messages and squiggly lines after you pasted code into the new project would be capable of breaking the toughest heart.

Partly confirmed my prejudices – a translation project is no way to learn .NET although it is perfectly feasible if you are already very familiar with the .NET Framework – although that begs a question or two.

Finding Framework Functionality

I don’t know about you but every time I think I am getting “on top” of the .NET Framework I discover something new and get worried that there might be more to be found that I have learned so far. Example:

I was reading a post by Matt Gertz who is a member of the VB language development team where he ‘fessed up to abusing the List Of() functionality to create a list of lists to support “undo” functionality in a demo VB app. Another member of his team pointed out the Stack object and Stack Of() of which he had been previously unaware. Now a stack would have been ideal for Matt; as it is a LIFO (Last In First Out) object and that was just what he needed to support “undo” functionality. Well that got me thinking, because a few days before a colleague had been working on a FIFO (First In First Out) object. After a bit of searching I found the Queue class and Queue Of() – just what had been needed. Neither the Stack or Queue class appeared in the Visual Studio help files as links from the List class or the Array class from which they are all derived.

How are you supposed to find this stuff? Plus don’t get me started on the version changes that invalidate huge areas of help available via your search engine of choice. Yes – almost all changes are framework changes but those have code implications. If you are regularly developing using the .NET Framework then you are probably tracking the main changes but again it is tough on someone just starting out.

Language Bloat?

The Beta2 of Visual Studio 2008 is now available for download and arrives at a time when a good number of developers are beginning to wonder about language bloat. There is a worry that language development teams keep packing in new features to little avail – are they making the languages more effective or are we just seeing a form of language marketing with a “feature race” designed to appeal to corporate decision takers?

Anyone who reads my blogs (erm anyone out there?) will know that I am a bit of an enthusiast for the nitty gritty of languages and compilers but they will also have noted (I hope) that I like my tools to provide effective feature while minimising duplication of functionality and I just hate features that feel like they are just there to “dumb down” the craft of code development. So bring on Lamda expressions and operator overloading in VB.NET but do I really need yet another way to select data?