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 (20)

  1. I didn’t really finish the discussion of what I began in this blog, so I’ll do so today.  Why do…

  2. Your site is very informational for me. Nice work.

  3. majkinetor says:

    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 ….

  4. buy xanax says:

    i like your website very much but please do get us more information about it

  5. Chris Retsrof says:

    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.

  6. MSDN Archive says:

    I never cease to be amazed at the nonsense people post to my blog.  

    1.  The overhead of using managed vs. native code is never going to be linear for highly complex apps.  There’s a fixed overhead for translating MSIL into native code.  After that, the performance is comparable.  People who’ve not written much mgd code are regularly surprised at just how performant it is.  It ain’t magic.  The compilation to native code has simply been moved to a later stage.  Compilers are fast enough that this isn’t that big of a deal, but the benefits are enormous.  The optimizations that many native code developers rely on are usually unnecessary and often dangerous.

    2.  Writing Notepad in C++ is at least 10x the code as that in C#.  It’s not the same no-brainer.  With more code comes the possibility of more bugs.

    Garbage collection is good for lots of things, not just non-locking resources.  It’s good for cleaning up any resource that might be in short supply.  It’s good for automatic resource mgmt in general.

    The advantages of foreach are obvious once you’ve actually used it.  It’s an order of magnitude easier to use than comparable iterator code in C++ because it does not require explicit casting or type coercion.

    3.  To compare the complexities of COM with those of .NET is intellectually dishonest.  That’s like saying driving my car and piloting the Space Shuttle are comparable because the both involve driving and they both have their own problems.  One is many times more fraught with difficulty and error-prone than the other, and guess which one it is?

    Like nearly every other API of any importance, the STA COM interfaces of the Windows shell are already wrapped in managed code and readily available to .NET developers, so no need for pity.  Re: DirectShow, no one ever said there would be no need for C++.  What I said is that for the majority of developers, it it makes little sense for them to build apps in native code now that the Framework is available and has mature compilers and development tools to support it.  I believe Russinovich’s concerns are unfounded and grounded mostly in ignorance.  He hadn’t built much mgd code when he wrote the article I reference.  And I don’t agree with your ‘horrific experience’ remark.  Build an app of some complexity with the Framework, then we’ll talk.  

    Garbage collection is a problem nearly every developer has, most especially the average C++ developer.  The average C++ developer makes mistakes wrt freeing resources or keeping them around longer than necessary.  The average C++ developer thinks nothing of allocating large buffers while an app runs and only releasing them when it closes down.  Garbage collection not only addresses the out-and-out leak scenario, it also helps apps be more efficient while they run.  It adds sophisticated memory mgmt that is simply beyond "the average C++ developer."

  7. Dev says:

    I really liked reading your article.  I completely agree with your observations that given an application, one must build it in a way which is quick, clean, less error prone, easy for others to read and follow, even though it may be 5-10% slower than native code. The myths about mgd. code being 10 times slower is greatly exaggerated.

Skip to main content