It is time to reconsider the recent past and ask the question "was .NET just a forced detour on the road to another technology?"

Before anyone explodes I'd better say that I don't have a definitive answer to the question that the title raises - how could anyone have such an answer. However the recent unsettling behavior at Microsoft has caused me to re-evaluate my .NET experiences and think hard about where it all came from and where it is all going. It is interesting and I promise not to be too provocative just for the sake of it...

First we need to remember why managed code was invented.

Back in the dark days of DOS Windows was amazing. No not the view of it the user got - the view that the programmer got. It was like nothing we had seen before. It was full of strange ideas like message pumps, window classes and the 16/32-bit architecture made it a nightmare with segmentation and near and far pointers to handle.

At the time Windows was written in C and so were Windows applications and they all worked by calling C functions that represented the Windows API. Over time things evolved and we got Visual Basic which made creating Windows applications much easier but it was slow and not strongly object oriented. The Windows API technology moved on from C functions to an object oriented technology - COM - and this worked well with Visual Basic as long as it was one of the more sophisticated forms of COM, either ActiveX or COM Automation. Working with COM was, and still is, not an easy thing to do from C++ but most programmers learned how to live with it.

You could also create Windows applications using Java but these weren't as well integrated with the APIs and so were something of a second class citizen. Microsoft had also had a big feud with Sun and was no longer allowed to produce its own JVM. At this point we were all waiting for Visual Basic 7 to be faster and more object-oriented but the VB community was waiting for an evolution not a revolution. Microsoft clearly envied Java and decided to dump everything and invent its own Virtual Machine based environment - and .NET was born. Everything that there was before was to be trashed - old style Visual Basic in particular and ActiveX and COM in general. Microsoft got its own replacement for the JVM in the form of the CLR and its own version of Java in the form of C#.

Programmers at the time felt threatened and mourned the passing of VB 6 but rejoiced at the demise of COM.

Over the years that followed C# developed into something that many would judge as better than Java. It might have started out as being similar but its pace of development turned it into a modern innovative language - and it's still innovating today.

Overall it has to be admitted that .NET isn't the terrible disaster everyone feared it might be. A good language and an ever growing class library makes it fairly easy to create applications.

However not everything in the managed code world is perfect. Most .NET programmers would identify the following as irritations of various proportions:

• The CLR could be as platform independent as the JVM but it isn't. Only the open source Mono project makes it available on Linux and the Mac.
• Over time it was expected that COM and ActiveX would be replaced by either managed equivalents or managed wrappers. You still have to spend a lot of time working with ActiveX and COM.
• It was also expected that new Windows APIs would come with managed wrappers and in time COM APIs would disappear - this hasn't happened. Try using DirectX 10 or later from C# for example.
• It was hoped C++ would become a fully fledged managed language, but C++ still isn't able to use WPF via a drag-and-drop editor.

This brings us to the latest developments of the .NET Framework - WPF and Silverlight. WPF is the upgrade to the basic Windows graphics system, i.e. the GDI and GDI+, to use the capabilities of the GPU via DirectX. 
A good idea yes - but there has been lots of moaning about inefficiency and stability. At the moment the only Microsoft application that uses WPF is Visual Studio and many users wish that it didn't.

Silverlight is a very reasonable idea. A plugin the allows .NET WPF applications to run in a browser. But which browser? At the moment however the real problem is that it isn't supported on enough platforms and cross-platform compatibility is still a problem.

This is just another manifestation of the fact that while .NET is in theory a platform-independent system Microsoft has little incentive to make it so.

I could go on listing the various side alleys of the .NET technology and listing problems but this would be to miss the bigger picture.

Microsoft was persuaded to go to managed code and to copy the Java infrastructure but in doing so it really failed to take the step that makes Java so attractive - platform independence. The .NET technology is mostly confined to Windows and, even taking Mono into account, its cross-platform support is weak.

So despite having thrown out some valuable assets to create .NET, it so far hasn't done Microsoft very much good at all. Java is still the number one language - or is it?

All the while that the .NET faction was developing its technology, the Windows systems programmers were carrying on using C/C++ to build COM APIs. Whenever a new API or an update was announced you could be sure that it would be COM-based and at best come with an imperfect managed code wrapper that left out the most powerful facilities. One of the big problems with using VB 6 was that it was a second class language when it came to accessing the API. Guess what, even with P/Invoke and COM interop, C# is still a second class language when it comes to accessing the API.

There has been, throughout the life of .NET, a steady but growing undertow to return to C++ and COM. Now the undertow seems to be growing and this is what prompts these thoughts.

If .NET has suffered from the lack of support from the C++ systems side it is also true that C++ has also suffered a lack of support from the language side. C++ has only recently acquired a managed UI via Windows Forms - not WPF you will note.

If you do want to go back to build a Windows C++ application how should you create the UI? At the moment you can pick between the MFC - huge and unwieldy, the ATL - easy to use but difficult to understand, the raw Win32 API, or a third party framework like Qt. Compared to the support that a .NET language gets from Windows forms or WPF this is not good.

Of course this is what we are being promised in Windows 8 - a new UI creation framework that works with C++ and other languages. We will have to wait to see how this turns out but so far it seems to be some sort of non-managed i.e. not CLR based implementation of something like XAML.

So has .NET been a big mistake?

Imagine for a moment that Microsoft hadn't forced us all to use .NET and instead VB 7 had been just an evolutionary upgrade. Presumably we would have settled on VB 7 for the "easy" applications and C++ for the more "demanding" applications. We would probably have seen the same sorts of Windows APIs developed, although without the wasted effort building managed wrappers to pretend that .NET was a first class citizen. Who knows perhaps C++ would have gained a better UI frame work possibly based on a markup language all the sooner. 

I ask you - what has the excursion into managed code  brought the Microsoft programmer and indeed what good has it done for Microsoft?

A mistake?

Who knows?

An unnecessary forced detour?

It certainly begins to look that way...

Further reading

Dumping .NET - Microsoft's Madness