Consider this, for example: By the end of the year, two platforms--J2EE and .Net--will essentially control the programming languages market. J2EE already commands large market share, while Microsoft has moved all of its languages over to .Net.
However, unlike five years ago, the differences between platforms is no longer that they are language-specific, as .Net and J2EE each represent more than one language. Interestingly enough, most people think that being language-specific is at issue. This is because Microsoft introduced the concept of the CLR, or common language runtime. What that means is two of the languages offered by Microsoft, VB.Net and C#, both share the same runtime.
I specified VB.Net as opposed to VB; even though Microsoft would have you believe otherwise, the two are really different languages. The key difference being that VB is a procedural language, and VB.Net is an object-oriented language.
Why would Microsoft make a change this fundamental to their most popular language? To make it work with the CLR of course.
This common language runtime isn't so common, after all, as it only really supports object-oriented languages. Still, it is an amazing achievement to be able to support different languages on the same runtime, right? I certainly think it is, but others would disagree.
Many are quick to point out that the JVM--Java's runtime--supports other languages as well. While this is true, it seems this is more of a hack than a feature of the JVM.
So today's developers will use one of three languages: Java, C# or VB.Net. How do these compare to C++ and VB, the languages that dominated the market five years ago? According to Microsoft, C# is the logical evolution of C++ and VB.Net is the logical evolution of VB.
If this is true, then how did Java get into the mix after starting from scratch only five years ago? As you may have guessed, many people see things a little differently to the way Microsoft does.
The route to Java
Developers switching from C++ to Java concluded that Java was the natural evolution of C++. This was because it offered similar object-oriented capabilities in a safer way, by making use of a runtime much like VB. Most assume that interpreted languages had long ago proven their advantages, elbowing aside compiled languages to a niche in high performance computing.
In fact, if one were to look at computer science departments across the country, you'd see that Java has replaced C++. So which language is really an evolved C++? The better answer is, simply, that new languages are more revolutionary than evolutionary. If we accept this, then VB.Net starts to make sense as a replacement for VB. However, one has to ask how different VB.Net and C# really are, given that they use the same runtime.
Not that long ago, a new concept was developed in the area of graphical user interfaces (GUIs) called skins. You could define the look and feel of a GUI separate from its functionality. An example of this is Windows XP. It becomes obvious to XP users that the look and feel is easily definable. In fact, XP even has a -classic" skin that allows it look like older versions of Windows.
Why do I bring up skins? Well there is a similarity of skins to that of .Net languages. With .Net, there is only a single runtime (functionality), but different language syntaxes (look and feel) can make use of it.
Of course, things are never that simple.
While skins allow you to define the look and feel of a window, for instance, you can't change the functionality of the window at all by changing its skin. Using this analogy, it's clear why VB.Net is so different than VB. While it was possible to preserve the VB syntax, it was impossible to preserve the same functionality on an entirely different runtime.
Look at some of the other languages that have been ported to the CLR. In every case, those languages have had to lose something important that made them different to fit the common dominator offered by the CLR. Microsoft has brought the notion of skins to programming indeed.
The question left for the reader is where this leaves developers. Was it a better world when developers could choose different languages based on the requirements of the application? Or should all languages do the same thing with different syntaxes? Microsoft has decided which way it prefers, and choice is out.
Matt Liotta has been a software architect for several start-ups in San Francisco and Atlanta. He is now an independent consultant and speaker at industry conferences.
I wonder what "features" MS has put into the CLR to prevent it being emulated in other OS's? The JVM was a definate threat to Monopoly as this environment could be ported to many OS's. Application software was effectively de-coupled from the OS that it was developed on. (MS tried to corrupt Java with J++ and incompatibilities)
Does anyone know what MS has done in the CLR to protect it's borders this time?