20 Aug
2006
20 Aug
'06
9:41 a.m.
Josh Dersch wrote:
You're actually suggesting writing multithreaded,
JDBC connection code
in raw assembly because it's more obvious when you've screwed up? Not
sure I follow the reasoning (I'd suggest hiring more experienced Java
coders), but more power to you on that effort :).
I hear this argument all the time (used to be about Visual BASIC) and
while I agree that making coding easier lowers the barrier to entry to
our "elite" club of the high UNIX priesthood, I don't think that it's
a valid argument to blame the language rather than the people involved.
Yes, and I keep hearing this same answer to that argument, however, I
find it to be less than honest.
Last I heard, Java, C, C++, and even Basic and assembly languages are
all used on various OS's, Unix being only one of them, so why the
priesthood comment?
The bottom line of my complaint is that garbage collection allows for
overly sloppy code, which you could never get away with in languages
that didn't have it.
The problem isn't writing JDBC connection handling in "raw" (as opposed
to what? cooked?) assembly. The problem is that in Java, you can get
away with allocating gobs of memory without having to free it, and
justify it with "Oh, the GC will clear it for me" however that attitude
does not work when dealing with JDBC connections, or file handles.
So, while you might be able to get away with writing sloppy memory
allocation code in Java, you can't get away with the same if it involves
JDBC connections, file handles, or network connections. This
inconsistency, that does cause problems in real life.
I pointed at C and assembly as examples of languages that lack garbage
collection. Because they lack this "feature", they therefore enforce
writing of better code, or force you to face much earlier crashes,
and/or a clear growth of memory footprint over time.
With Java, the memory footprint climbs up and down over time as the GC
is invoked, and if the GC has to do a lot of work, the JVM freezes, and
many memory leaks you may have are masked by the GC. You don't really
know if you have a leak or not until it's too late (when you see your
JVM has a 2GB footprint and is doing GC's that take over 60 seconds to
complete), and even then, its difficult to locate it amongst several
thousand threads.
I do think that it is proper to blame every language for all of their
shortcomings - please do not pretend to hold some sort of high moral
ground by claiming to uphold a language as some sort of godly
perfection, while in the same breath, you have turned up your nose at
the idea of writing threaded database connectivity drivers in "raw"
assembly.
Granted, bad code has many reasons, including artificially tight
deadlines, features driven by politics, unclear specifications, and yes,
even sloppy coders. But don't fail to call out the flaws where you find
them - even if they happen to be in a favored or popular language.