IT'S LIFE, JIM (but not as we know it)...

Language tends to be an emotive issue. Java people look upon on C# users as little more than Microsoft slime mould. C++ programmers think that Visual Basic users have barely descended from the trees. And so on – all cases of “my compiler’s bigger than yours. So there!”.

Many programmers develop a fixed attachment to a specific language at some point in their careers. I remember being particularly fond of a now dead language called Algol68 many years ago. It was truly heartbreaking to find that the rest of the world did not share my particular passion. Even worse, they weren’t going to pay me to indulge it either.

Most of us grow out of this, though. I really don’t care what ‘make’ my automobile spanners are, so long as they fit the nut. The same with languages. If someone wants to pay me to program in QBasic – fine by me.

Something Old, Something New…

But, at last, it seems to me that something interesting is happening to programming languages - we are entering a new and unpredictable phase in their evolution. For many years we’ve been fed the same diet of Java and C++. Pretty boring it’s been too - I really can’t get worked up over another underscore directive being added to C++. Reading about ‘revolutionary’ Java sends me to sleep. There have, to be sure, been a few ad-hoc languages around, like PHP, and useful things, like Perl, but nothing really exciting.

This is now changing. Not for any one reason; it’s more like a convergence of different forces and technologies. And this could have profound consequences.

Let’s have a look at where we are now. Visual Basic is in decline, nobly assisted by Microsoft. In the past Visual Basic was the pre-eminent Rapid Application Development (RAD) tool. The idea of a point-and-click programming interface was revolutionary when it was introduced. But now C# can do the job just as well and, if I were learning a language, I wouldn’t choose Visual Basic .NET. From a purely selfish point of view, learning C# gives me access to both C# and the Java market. In reality, there’s really very little difference between the two languages: the main learning curve is in the APIs and the libraries.

I’ll start with C#. I’ve been writing a fair sized application in C# recently. While I’ve used VB .NET quite a bit, I’ve never written anything more than a “hello world” application in C# before. I was struck by a number of things. First, I picked it up with little difficulty. My main problem was that I kept leaving off the semicolon terminators - in VB .NET, of course, you don’t have these. Secondly, I was expecting to make extensive use the ‘unsafe’ coding directive for handling unmanaged memory. In fact I didn’t – I used it a few times, decided it was useless and went back to the marshalling technique I’ve used previously in VB .NET. This was decidedly odd. I’ve often moaned about the difficulty of interfacing to unmanaged memory in VB .NET. Now I find that it’s just as bad in C#. I’d often wondered about the lack of examples of unsafe programming on the internet. I’ve found out why: unsafe programming is pretty useless.

The reason is rather obvious once you’ve used unsafe programming. A pointer to some unmanaged memory isn’t a great deal of use. You still have to Marshal the data into managed objects at some point. All that the unsafe mode does is hide the marshalling from you – and that’s not a great help. I’ve found it clearer and less error-prone to marshal the data explicitly.

The third thing I found was that I didn’t use C#’s object orientation much and where I did (overriding base classes, etc.) it was more trouble than it was worth. I’ll give you an example. Let's suppose I have an enum with three members in a base class and I need to add a fourth member. You can’t derive a class from an enum and do it that way. You have to modify the original enum in the base. I ended up making a copy of the base classes and hacking away at those. To my mind there wasn’t much point in having all those overrides and so on in the first place – I ended up editing the base class anyway. In addition, I have to say that, in general, changing the base class is a lot easier and more obvious than figuring out what overrides what.

I’m sure that some purists would argue that the problem is with my design of the class structure (in fact, the classes were Microsoft’s – not mine). However, the problem isn’t that. It’s that C# isn’t a fully object oriented language – an enum isn’t a fully fledged object. When I first came across this I spent some time trying to figure a way round this problem. But there isn’t a way round (as far as I can see). If you have an enum in a base class you can’t safely extend the enum without re-implementing the base class.

In general, I still prefer writing in Visual Basic. Why we are still using a register increment operator (++) from a pre-historic PDP assembly language in a fully memory managed application beats me. But the final (and most overwhelming) thing that I really noticed about using C# over VB .NET was that there was absolutely no advantage whatsoever in VB .NET over C#. If I was starting a development of any size now, I would unhesitatingly choose C# - and I speak as a fan of VB and VB .NET. A further point: Microsoft itself uses C# far more than VB .NET. As I’ve said before, it all points to a fairly gloomy future for VB.

C++ Return Of The Living Dead

Now lets’ look at C++. This is getting interesting – and the reason is .NET. If you’ve ever tried to deal with unmanaged memory and COM from .NET, you’ll understand why Microsoft has had to revamp C++. It’s clear that a lot of Microsoft software is written in unmanaged code using COM. I’d go further and say that the overwhelming amount of Microsoft products are COM based. Visual Studio certainly is, and I would guess that Office is too. COM and the CLR (the .NET Common Language Runtime) don’t mix well. The basic problem seems to be that COM and CLR interoperability was only added as an afterthought rather than being designed in at a fundamental level. For example, not all COM data types are supported in the CLR. That’s bizarre – and it means that you often have to have a ‘shim’ between the COM world and the managed CLR world. And the language to write the shim in is – yes, C++!

I feel that the best language to write a COM object or interface in is C++ using templates and the excellent ATL (Active Template Language) system. The best way to debug a COM object is via low level debugging in Visual Studio. But once you get into the interface between COM and the CLR – the COM Interop – you effectively drop into a black hole; it’s extraordinarily difficult to trace a problem if one occurs somewhere around there. I’ve just spent the best part of a week trying to track one fault down. In the end, I gave up and reinstalled both the operating system and Visual Studio. I’ve still no idea what caused the problem. All I can say is that I didn’t change any of my code – but after the re-installation, it all worked fine. DLL hell or .NET hell? I simply don’t know. Worse, I had no way of finding out.

Originally, when .NET was released, Microsoft (along with many others) expected C++ to sort of fade away as the world embraced managed code. It hasn’t happened – and I don’t think it will. There was even some expectation that Longhorn/Vista would have a managed interface to the fundamental Windows APIs, so that you’d never need to do a DllImport again (see http://www.winsupersite.com/faq/longhorn.asp for an example of how it was supposed to be) . I suspect that this was always wishful thinking. The design of Windows does not generally lend itself to managed code – there are something like 80,000 APIs in Vista and Microsoft seems to be adding more all the time. To wrap that lot in a .NET framework, test it, debug it and document it is a vast exercise. At the end of which, all you’ve got is a layer which adds nothing in functionality and simply slows things down. It’s not going to happen any time soon.

So Microsoft is busily revamping and dusting off C++ as the solution  to the managed/unmanaged memory problem: write the unmanaged bits in C++ and use the COM interop to link up with managed C# classes seems to be the message. But if you think about it, this is a really retro way of doing things. I recently had a look at Borland’s new Developer Studio. While I wasn’t tempted to move away from Visual Studio 2005 (which I really think is a truly excellent product, by the way), I  was struck by the fact that Borland has used one language, Pascal, to address the problem of writing applications which have to address both WIN32 and .NET APIs. I can believe that this wasn’t that easy to do, but it has done it. If Borland – with far fewer resources than Microsoft can do it, why can’t Microsoft? Why have this strange C++/C# hybrid?

I think the answer goes back to Microsoft’s obsession with Java. C# had to be as Java-like as possible and its designers (who didn’t have a Microsoft background) weren’t too bothered about COM backwards compatibility. In the brave new world of .NET, such things didn’t matter. After all, everything would be using managed APIs in a couple of years. Well, they aren’t. There are few .NET applications out there. Personally, I’ve only used two (and I wrote one of them!). No doubt eventually there will be more. But it’s a slow, slow process and, I would surmise, much slower than Microsoft anticipated.

But Microsoft owns C# - so it can be changed. It is changing. So is Visual Basic. And there are other languages out there: Python, Ruby, F# and Scheme and so on - all of them playing a part in the ongoing evolutionary process. Strangely, the one that doesn’t seem to be evolving  is Java. I’ll look at some these languages next month.

Bytegeist Archives