Doug Ross @ Journal

Grimes Sets Off a Firestorm

The eloquent Richard Grimes, of Dr. Dobbs Journal fame, recently set off a firestorm in the software development corner of the blogosphere. Having written a .NET column for three years, he'd come to the end of the line. His reasoning? Read the whole thing, but here's his summary.

...Microsoft's current operating systems, XP and Windows 2003, do not depend on .NET; and with XP, .NET is an optional component. The next version of Windows, codenamed Longhorn, was released as a technical preview at the 2003 PDC, and it looked as if the operating system would have .NET's tendrils throughout. However, a lot has changed since then. ...I have a very cynical opinion of .NET. The framework has a lot of promise, but I think Microsoft was far too ambitious releasing far too many assemblies much too quickly. As a result design suffered [and]... we are stuck with the library we have... [.NET is] intended for users to develop applications, but not for Microsoft to create operating systems or the revenue generating products that they base their profits on...

In other words, Grimes posits that .NET is a sort of "development-lite" environment that carries a heavy run-time penalty (which, surprisingly, doesn't even come with the operating environment).

Dan Fernandez, Microsoft's Visual C# Product Manager, responded to Grimes' criticisms in his own blog entry. But I found the most compelling remarks in the comments on Fernandez' blog, not the blog post itself. Here's one that resonated with me, as a commercial software developer:

# .NET Distribution should not be a developer burden 3/7/2005 6:29 AM Mark Munz The fact that Microsoft has NOT pushed .NET frameworks onto Windows machines lends to the lack of credibility in Microsoft's claim that .NET is the future... client side deployment of the .NET framework is crucial. Not every app is going to be server-based... Putting the burden of redistributing the .NET framework on the application developers is unprofessional for an OS company. And fear of taking some flack for including the .NET framework in a SP has got to be the lamest excuse I have ever heard... So smaller developers are left telling their customers -- yes, our application is 1MB, but you have to download a 25MB framework first. That's right, you have to download and install a component that is 25 times the size of our application in order to use our application. The result, we -- the smaller developers -- are the ones who look unprofessional... The truth is that it is mainly Microsoft's own fault that .NET is not more widely used today.

Another heavy-duty software blogger, Mark Lucovsky, weighed in with some meaty remarks on the nature of shipping software.

Consider the .NET framework for a second. Suppose you wrote something innocent like a screen saver, written in C# based on the .NET framework. How would you as an ISV "ship your software"? You can't. Not unless you sign up to ship Microsoft's software as well. You see, the .NET Framework isn't widely deployed. It is present on a small fraction of machines in the world. Microsoft built the software, tested it, released it to manufacturing. They "shipped it", but it will take years for it to be deployed widely enough for you, the ISV to be able to take advantage of it. If you want to use .NET, you need to ship Microsoft's software for them. Isn't this an odd state of affairs? Microsoft is supposed to be the one that "knows how to ship software", but you are the one doing all the heavy lifting. You are the one that has to ship their software the last mile, install it on end user machines, ensure their machines still work after you perform this platform level surgery.

Exactly. Well put.

One of my current popular downloads (over 1.2 million copies downloaded) weighs in at under 700K and doesn't come burdened with a ginormous runtime.

.NET done right would utilize a lean, on-demand framework that could be loaded as needed, right off the network if available. In the meantime, I can't use .NET for client-side apps for the reasons specified above.