“Putting your toys away when you are done is always a drag, but if you dont take the time to do it, you would have a huge mess over time. Garbage collection does an awful lot of the cleanup for us, and it simplifies development and eliminates entire categories of potential code errors, but some java resources still require explicit action on our part. This article discusses the limitations of garbage collection and identifies situations when you have to do your own housecleaning.”
This reminds me C programming isn’t as troublesome as it used to be.
In Java you write shonky code and the GC cleans up for you (sometimes, as is nicely illustrated here).
In C you write shonky code and then (these days) use Valgrind to find memory leaks.
Otherwise, you need to *think* to come up with something good.
So in Java you save time by not having to run Valgrind to find your leaks.
And in C you save time by having your finally finished App run … hmm twice as fast? (pulling the number out of my xxx)
I prefer the later for apps that I use, on my desktop.
I have seen programs going down the drain in their development process due to the usage of C++, in the late 90s many of the server projects with dozuends of programmers were axed due to costs going haiwire, mainly caused by the deficiencies of C++ regarding memory protection and garbage collection and its byzantine syntax.
There was a reason why people switched to java in masses and that reason was, that you could pull such projects in a timeframe of months off where it would have needed years to stabilize it in C++. Sure the situation has become better than it used to be thanks to tools like valgrind, but there still is a difference. There are a lot of usecases out there where programs have to run for years from day 1 of deployment, and doing such programs in C is doing it with the wrong tool, unless you have a lot of time on your hands. That´s where languages like java, smalltalk and pretty much every interpreted language jumps in.
As for client side stuff, java used to be bad until JDK 1.4 but there is no real reason anymore not to use java on the client side. Swing has become fast enough.
There was a reason why people switched to java in masses and that reason was, that you could pull such projects in a timeframe of months off where it would have needed years to stabilize it in C++. Sure the situation has become better than it used to be thanks to tools like valgrind, but there still is a difference. There are a lot of usecases out there where programs have to run for years from day 1 of deployment, and doing such programs in C is doing it with the wrong tool, unless you have a lot of time on your hands. That´s where languages like java, smalltalk and pretty much every interpreted language jumps in.
That statement itself is almost laughable; If C++ is the tool for the job, a good software engineer who knows the language can get the job done just as easy as in Java. Years to stabilize a program in C++? Thats a problem with the engineers, not with the language.
Also, you mention that C is the wrong tool for applications that have to run for years from day one of deployment? Hmm, lets rewrite Linux in Java, and see how far we get…
Edited 2006-03-23 12:52
Thats a problem with the engineers, not with the language.
Indeed.
I’m with Joel(OnSoftware) in that having the best team of software engineers is critical.
Some managers have the idea that all programmers are born equal. It’s a lovely vision for them – “employ the cheapest you can find, and STILL get your robust high performance computer system!” (this is also why everyone drives a Porsche, not just those who can are prepared to pay for quality. errr… hmmmmmm… oh yeah…)
IMHO, features such as GC in Java have lowered the bar such that slightly more cretinous people are able to find their way into the software business than before, and clueless management have been suckered into believing that humans are getting all that much better at building software, thus any old software people will do.
Quit re-hashing the mythical man-month Joel. A parrot is not intelligent. Yes it’s a good book, but Fred Brooks said it much better than you.
And as counterpoint to the article, it’s important to remember the advantages of the GC:
http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html
Our experience with the Java GC is that it absolutely dies when you’ve been running for a few weeks with small memory allocations (<100K) and then throw in a huge one (’round a 1G).