Why .NET is the best thing to happen to software since OOP
I read a blog by Mark Russinovich the other day that disturbed me a bit. It always bothers me when someone as highly regarded as Mark completely misses the boat because it means that a lot of other people will probably miss the boat, too. People often read things written by people they respect and immediately take them to the bank without critically considering whether they really make sense. So, given that, let me try to rebut what I think is some faulty logic and some misguided concern on Mark's part.
First, to summarize his blog, he's worried that people will begin developing client-only applications in managed code (rather than those spread across a client and server) and the result will be an enormous bloat in resource usage and a big slowdown in performance for the typical app. He goes on to compare a managed code Notepad-like app with Notepad.exe and shows the huge difference in resource utilization and performance. Not surprisingly, the managed code application requires much more memory than its native code counterpart, uses more CPU, and is generally less efficient.
For Mark, this was irrefutable evidence that native code was preferable to managed code -- especially for standalone apps -- but there are several problems with this type of reasoning. Let me iterate through a few of them:
1. Notepad.exe isn't a typical app. It's far simpler than most applications. Assuming a fixed amount of resource overhead for any app built with managed code, comparisons between native and managed code involving simple apps like this will, of course, favor native code. But the overhead is not linear -- it is more-or-less fixed -- and, the more complex the app becomes, the less of an issue the additional resource utilization becomes. At some point, it's not a factor at all.
2. To fairly compare managed code and native code, we should take a hard look at what we get for the additional expense managed code brings with it. The benefits are many, even for tiny apps like Notepad. First is ease of development. Mark, have you compared writing in C++ vs. writing in C#? Let's take that Notepad managed code app you mentioned. It consists of about 470 lines of code, most of which was generated automatically by Visual Studio. Conservatively, I'd say there aren't more than 200 lines of actual code in the app. How many lines of C++ make up Notepad.exe? I'd wager it's at least five times that many. And it's in a language that doesn't offer automatic garbage collection, foreach, or many of the other things that make managed code development both safer and faster for the average developer. There's a huge productively advantage in using a managed code language that Mark's diatribe fails to take into consideration.
3. The notion that the .NET Framework is just about competing with Java is narrow-minded and myopic. First, the Framework owes as much to Delphi for its heritage as it does to Java. Delphi was the first language tool to build a PME (Property-Method-Event) paradigm of development on top of a rich OOP foundation. Pre-Framework VB only approximated an OOP development model; Delphi actually delivered on this. Anders Hejlsberg extended what he had begun in Delphi via his work on C# and the Common Language Runtime. Yes, one aspect of Microsoft's managed code initiative is to compete with Java. Of course. Just as one aspect of Sun's invention of Java was to compete with Microsoft's language tools of the time. But that's hardly the whole story. CLR and managed code were as influenced by Delphi as they were by Java.
Second, the CLR is not just about competing with other language products or extending them. It's about making development easier, especially on multiple platforms. Java doesn't have a monopoly on multi-platform development. People have been writing (or trying to write) portable code for decades. Remember C? Part of the original premise of C was that you could write code once and compile it for multiple targets. We've been chasing the mythical write-once-run-anywhere unicorn for as long as there have been purportedly portable languages.
Third, keep in mind that the CLR is as much about solving certain long-standing development problems as it is about competing with other language tools. COM is notoriously difficult to write code for. Most anyone who's written a complex COM app in C++ will attest to its many pitfalls and rough edges. It was not originally intended for novice or intermediate developers. VB's support of limited COM development was intended to address this, but it was never completely successful. Even with the advent of VB, the lion's share of hardcore COM component development still required C++, and the CLR was intended to mitigate this. It was intended to make software component development much simpler and much more accessible to the average developer. It was intended to do away with arcane requirements such as release counting and IDL, and move some of the onus of managing application resource and component utilization on to the runtime rather than the developer. It dismissed, out of hand, the silly notion that "real developers don't use runtimes" and instead focused on providing the infrastructure required to let the developer focus on the business problem she was trying to solve rather than on the plumbing necessary to make her code work.
Far more than a Java wanna-be, the CLR is about solving longstanding development problems and needs that have bedeviled language tool vendors as long as their have been languages.
When 3GLs first came on the scene, they had the same type of criticisms leveled at them. Pundits happily showed the astonishing difference between a "Hello, World" app written in assembly language versus one written in C. The C app was ten times larger! It used three times the memory! What was the world coming to?! Then someone sanely pointed out that the typical app would be a tad more complex than "Hello, World," and people began building apps with the new 3GLs and forming their own opinions. The rest is history. No one but Steve Gibson writes real apps for the PC in assembly language anymore. Notepad is the "Hello, World" of our age. Apps are much more complex these days, and Notepad is about as simple as they get. Leveraging resource usage comparisons between a managed code and a native code version of something like Notepad to bolster an argument in favor of native code is not only unfair to managed code, it's foolish. To be fair, you'd have to compare all aspects of the development lifecycle in the construction of a real app, not a do-nothing simpleton like Notepad. You'd have to look at the supportability and extensibility of native code vs. managed code, at the number of post-partum bugs and the time required to fix them, and the ability of the code to be easily ported to multiple platforms. Mark's blog doesn't even attempt any of this, and, will thus very likely lead a lot of people astray.
Code generation for managed apps will get better over time just as it did for native code apps. Resource utilization will become more efficient. The managed code world will evolve just as the 3GL world did before it, and the first-generation and second-generation worlds before that. To get up in arms before this has had a chance to happen is premature. One must look at the whole picture -- not just resource utilization or binary file size -- and must take a long view of the whole process, viewing it in the perspective that comes from knowing the language tools that came before it. Even now, in its infancy, I believe the managed code story compares favorably to native code development and plan to do most of my new development in it.
Comments
Anonymous
April 19, 2005
I didn't really finish the discussion of what I began in this blog, so I'll do so today.  Why do...Anonymous
September 01, 2005
Very nice blog.Anonymous
March 21, 2006
Your site is very informational for me. Nice work.Anonymous
May 03, 2006
The good things dotNet added in programming community are already available in Delphi for so many years.
I don't see benefits of using dotNet languages over Object Pascal.
This can be continued on story about Visual Studio vs. Delphi developement ....Anonymous
June 03, 2006
i like your website very much but please do get us more information about itAnonymous
August 01, 2006
funny ringtonesAnonymous
August 20, 2006
I have to disagree:
1. The overhead might be linear (seems to be roughly 24 MB as you start using the UI classes) but people have started to develop simple update notification taskbar applications in C#.
2. Writing a notepad application in MFC or WTL is the same nobrainer as in C#. Garbage collection is only good for non locking resources as memory. .NET languages except C++/CLI do not offer deterministic destruction which makes handling locking resources extremely dangerous in C#. And having to implement two types of destructors in C++/CLI is a bad joke. What's the big advantage in having a foreach statement?
3. Yes, COM isn't easy, but .NET has it's own set of very serious problems. I pity the poor pure .NET developers having to use the STA COM interfaces of the windows shell. Or how about building a DirectShow capture graph in C#. What a horiffic experience trying to manage a deterministic release of the hardware and having to write all those using statements is far from productive.
Garbage collection fixes a problem average C++ developers don't have.Anonymous
October 20, 2006
The comment has been removedAnonymous
May 17, 2007
The comment has been removedAnonymous
June 01, 2009
PingBack from http://portablegreenhousesite.info/story.php?id=14517Anonymous
June 08, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=789Anonymous
June 09, 2009
PingBack from http://toenailfungusite.info/story.php?id=9540Anonymous
June 16, 2009
PingBack from http://fixmycrediteasily.info/story.php?id=3875