http://www.joelonsoftware.com/articles/APIWar.html
Automatic Transmissions Win the Day
Don't get me wrong... I think .NET is a great development environment and Avalon with XAML is a
tremendous advance over the old way of writing GUI apps for Windows. The biggest advantage of .NET
is the fact that it has automatic memory management.
A lot of us thought in the 1990s that the big battle would be between procedural and object
oriented programming, and we thought that object oriented programming would provide a big boost in
programmer productivity. I thought that, too. Some people still think that. It turns out we were
wrong. Object oriented programming is handy dandy, but it's not really the productivity booster
that was promised. The real significant productivity advance we've had in programming has been from
languages which manage memory for you automatically. It can be with reference counting or garbage
collection; it can be Java, Lisp, Visual Basic (even 1.0), Smalltalk, or any of a number of
scripting languages. If your programming language allows you to grab a chunk of memory without
thinking about how it's going to be released when you're done with it, you're using a
managed-memory language, and you are going to be much more efficient than someone using a language
in which you have to explicitly manage memory. Whenever you hear someone bragging about how
productive their language is, they're probably getting most of that productivity from the automated
memory management, even if they misattribute it.
Racing car aficionados will probably send me hate mail for this, but my experience has been that
there is only one case, in normal driving, where a good automatic transmission is inferior to a
manual transmission. Similarly in software development: in almost every case, automatic memory
management is superior to manual memory management and results in far greater programmer
productivity.
If you were developing desktop applications in the early years of Windows, Microsoft offered you
two ways to do it: writing C code which calls the Windows API directly and managing your own
memory, or using Visual Basic and getting your memory managed for you. These are the two
development environments I have used the most, personally, over the last 13 years or so, and I know
them inside-out, and my experience has been that Visual Basic is significantly more productive.
Often I've written the same code, once in C++ calling the Windows API and once in Visual Basic, and
C++ always took three or four times as much work. Why? Memory management. The easiest way to see
why is to look at the documentation for any Windows API function that needs to return a string.
Look closely at how much discussion there is around the concept of who allocates the memory for the
string, and how you negotiate how much memory will be needed. Typically, you have to call the
function twice—on the first call, you tell it that you've allocated zero bytes, and it fails with a
"not enough memory allocated" message and conveniently also tells you how much memory you need to
allocate. That's if you're lucky enough not to be calling a function which returns a list of
strings or a whole variable-length structure. In any case, simple operations like opening a file,
writing a string, and closing it using the raw Windows API can take a page of code. In Visual Basic
similar operations can take three lines.
So, you've got these two programming worlds. Everyone has pretty much decided that the world of
managed code is far superior to the world of unmanaged code. Visual Basic was (and probably
remains) the number one bestselling language product of all time and developers preferred it over C
or C++ for Windows development, although the fact that "Basic" was in the name of the product made
hardcore programmers shun it even though it was a fairly modern language with a handful of
object-oriented features and very little leftover gunk (line numbers and the LET statement having
gone the way of the hula hoop). The other problem with VB was that deployment required shipping a
VB runtime, which was a big deal for shareware distributed over modems, and, worse, let other
programmers see that your application was developed in (the shame!) Visual Basic.
Sidebar
Why does automatic memory management make you so much more productive? 1) Because you can write
f(g(x)) without worrying about how to free the return value from g, which means you can use
functions which return interesting complex data types and functions which transform interesting
complex data types, in turn allowing you to work at a higher level of abstraction. 2) Because you
don't have to spend any time writing code to free memory or tracking down memory leaks. 3) Because
you don't have to carefully coordinate the exit points from your functions to make sure things are
cleaned up properly.