Why .net isn’t a win for industry

I wrote this in early November 2003 after getting disgusted with the hype surrounding .net. I think that on balance the years have been kind to this essay. I sure haven’t seen .net set the world on fire.

In the five years since, .net 2.0 and 3.5 have been released, as well as Java 1.6. Please remember that when this essay was written, .net 1.1 and Java 1.4 were state–of–the–art.

Lately, there’s been a lot of hubbub about Microsoft’s .net platform. I’ve been playing around with it for the last few weeks and have come to some conclusions, the chief one being that while it’s an interesting technology, it’s not going to be a win for industry. Nor is it, in and of the new things it brings to the table, going to result in better software. Instead, I think .net is actually going to make the software crisis worse.

What is .net?

Amazingly, there is no clear answer!

I spent a few weeks asking this question before I came to a sensible answer. Part of the problem with .net is the very difficulty of coming up with an answer to “what is .net?” Any technology which cannot be succinctly defined is doomed to fail. Good technologies solve narrowly–defined problems; successful technologies solve narrowly–defined problems in ways which lend themselves to also solving other problems in heretofore unknown ways.

The lack of a narrowly–defined problem is indicative that .net is not going to be the salvation of the software industry, as Microsoft seems to be hoping.

I never was able to come up with an answer, but I eventually stumbled to a definition:

.net is an uninteresting virtual machine.

This is where I began to really question if .net was a win for industry; after all, don’t we already have a perfectly good stack–based virtual machine in the Java vm? Even Java’s vm isn’t all that interesting. Scheme48’s vm and Parrot both strike me as interesting; the jvm strikes me as useful; and .net strikes me as a significant reinvention of the wheel.

Sure, .net has an interesting trait in that there are many languages which can be compiled down to .net bytecodes. But on the one hand this is misleading, and on the other this is still not new.

.net’s claim to fame is false

It’s misleading to say many languages can be compiled down to .net bytecodes. It’s misleading because .net does not support the full richness of all paradigms.

On October 21st, 2003 I had the great good fortune to speak with Professor Hal Abelson of mit. Professor Abelson is one of the principal figures behind the Scheme programming language, which may be the most elegant lisp dialect out there.

I asked Professor Abelson whether Scheme could be represented in the .net virtual machine. His answer was a clear and unambiguous “no”. Most of the language can be; but one of Scheme’s most useful and unique facilities, continuations, cannot be modeled in .net’s vm. It’s not that nobody’s done it yet; it’s that it’s not possible.

Why is it impossible? For the most pedestrian of reasons: Scheme’s engineering goals are in conflict with .net’s. One of .net’s goals is to provide a safe execution environment. As such, it gives programs no access to the stack. This is a defensible choice and I do not hold it against Microsoft. But, without access to the stack, it is not possible to correctly represent continuations.

.net does not support multiple languages

Microsoft has claimed to have Scheme running on .net. As it turns out, if you read the fine print they’re actually running a subset of Scheme on .net. This is going to be more trouble than it’s worth; why would a diehard Scheme programmer, one who’s spent years mastering the language and uses continuations like Mozart uses a piano, ever want to use .net?

The same applies to C++. The current .net virtual machine does not support templates. Suddenly, C++’s Standard Template Library gets thrown out the window. C++ programmers who have made the investment in learning templates are going to be unlikely to want to make this sacrifice.

The same applies to any language which relies on multiple inheritance. .net prohibits mi under the theory that mi is evil and should be discouraged. This may be true, but it’s a fact that many existing languages support mi and thus cannot be faithfully represented in .net.

What it amounts to is this: .net does not support multiple languages. It supports restricted subsets of languages, and the portions which are discarded are the portions which make certain languages so much more useful than others.

Java is in the same boat as .net when it comes to this. There’s all manner of languages you can compile down to Java bytecodes, but usually only a subset of the language is supported. In Java’s favor, though, they’ve never claimed to be a truly universal virtual machine.

Languages aren’t the problem, anyway.

The second reason is more pernicious. It implicitly casts programmers as being incapable of adapting to a changing environment. Businesses are seeing .net and saying, “oh, this is wonderful! Now we’ve got one unified target for all our development, and we no longer have to go out and hire programmers who have experience in our particular language!”

In other words, Microsoft is catering to the software industry’s worst practice instead of attempting to build on the industry's best practices.

Programming languages are irrelevant to good programmers.

A good programmer with a good education can pick up a new language in three days flat. Actually getting the education is hard; but putting the education to use once it’s earned is really easy.

So if you’re hiring good programmers, then why do you care about what language your programmer knows? If the programmer only knows Standard ML, cobol and Smalltalk but has an excellent Computer Science education, does it matter that your company writes Visual Basic or C++ or RPG? The answer is—no, it doesn’t. If the applicant is a good programmer, hire, regardless of whether or not they have the language you want listed on their resume.

And if you’re not hiring good programmers, then isn’t the fix for that to change your hiring practices, and not to commit yourself to a new platform in order to spare your substandard programmers the headache of learning something new?

.net will exacerbate problems, not solve them.

If your firm has an expert C++ programmer, a professional in every sense of the word, what’s her reaction likely going to be when she’s told that, due to company policy, she’s no longer allowed to use templates or multiple inheritance since they’re not part of the new .net policy?

If you’re lucky, her morale will remain high and she won’t quit on the spot. Assuming you’re that lucky, she’s still going to be essentially lobotomized. All those years spent mastering difficult skills have now been thrown away; the years spent accumulating expertise have been discarded. She’s now thrown back into the lowest–common–denominator environment that .net creates, and she’s going to find it very difficult to rise above it because .net will deny her access to her specific, specialized skills which make her such an effective programmer.

If your business makes a habit of denying exceptional programmers the tools they need to excel, your business is not fit to survive. Policies like this are inhumane and undignified.

So already we’ve seen that optimistically, committing to the .net platform will lobotomize good programmers, if not drive them out. This is an unarguable loss.

Now let’s look at the flipside. Yes, it’s true that .net will allow programmers who know Visual Basic to coexist with programmers who know C++ and programmers who know Java. But we’ve already established that you only need this if your programmers are such slack–jawed gutbuckets that they can’t learn each other’s languages in a week.

So here’s what it comes down to: .net is the triumph of the losers. .net is going to give the lowest caliber of programmers more jobs, and is going to either lobotomize or drive out good programmers.

Does it still sound like .net is a good idea?

.net is not useless; it’s just marketed uselessly.

All this said, there’s a very good reason to look favorably on .net. It’s a product–improved Java. The .net virtual machine is more easily targetable by other languages, even if we do have to qualify that extensively. Java will likely have to make the jvm similarly easy to target as a result of the competition from .net.

Java is introducing weak generics to Java 1.5. .net is introducing generics in version 2.0 of the .net Framework. It’s pretty clear that they’re in competition with each other here, too.

Basically, Java is becoming a better language because it has .net breathing down its back. And for that reason, .net has a very real and strong use: as a credible competitor to Java it’s advancing the state of the art.

Concluding remarks

During the dot–com boom I had a lot of complaints about the way Java was hyped. I remember reading in trade journals that Java was going to wipe out all other languages. A friend of mine who worked at a major bank told me in fearful tones about how management had pronounced all their legacy cobol apps would be rewritten in Java within five years. (Fortunately, this plan never came to pass.) The hype was just incredible, in both the “spectacularly huge” sense and the “not at all believable” sense.

Eventually we all came to our senses and revised our opinions about Java. We now have a more nuanced view of Java and can recognize it as a valuable contribution to the industry. It didn’t change the world, but it did make things better.

I imagine the same thing is going to happen with .net. In five years we’ll look back on the claims being made today and laugh at how few of them came true. .net will likely become an important development.

But we won’t be able to discover the nature of that development until such time as we look at .net with open eyes, unburdened by hype and spectacle.

Email me.