RoboProg's / Software Development
Garbage collection: friend or foe?
Java solves some problems: C and C++ buffer / string overruns and exploits are pretty much a thing of the past for most in-house "Enterprise" applications; Server code binaries pretty much run on most common operating systems.
Java makes some new problems: On the fly scripting development is only recently supported; Java is slow; Java is an incredible memory hog.
It would not be fair to compare Java to C or assembler, so I won't. I will, however, compare it to Perl. Perl (5.x) seems to be much faster than Java for things that I have measured side by side in the past. So, it's possible to have an interpreted language that does at least as well as Java. Unfortunately with regard to Perl, it appears "that parrot is dead". Perl 5 gets tweaked, but Perl 6 is lost in an enormous upgrade. I also have my doubts about Perl 6 / Parrot for reasons I will discuss below.
Big, fat, Java? Again, use Perl as a comparison (sorry I don't have numbers handy -- this was test code that I wrote at a previous job). What I remember, albeit a few years and versions back, is that Java was easily twice as slow (or more) than Perl at many string lookup and I/O activities, leading me to favor high volume work in Perl, rather than Java, in some cases (those cases being that it wasn't necesary to break down and "do it in C").
It seems to me that one of the biggest problems in Java, performance wise, is the mark and sweep garbage collector itself. The GC allows you to avoid most memory leaks, but the (high?) cost is that it destroys locality on a virtual memory system. "But I have plenty of RAM on my server!" you say? Not so much: think of your RAM as just a level above the swap partition / file. Think of the "real memory" as being the L1 and L2 caches on your chip(s). So, we are once again back to having about a megabyte, half or double, of fast memory, with slower backing storage elsewhere. I guess I'm still preoccupied with 1985, or at least experiencing the same sort of limitations all over again. That said, all of this activity by the garbage collector, even if it is a more advanced one, such as a generational GC, is frequently pulling in all of this unused / uninteresting secondary storage into main storage, which causes a fair amount of cache misses for the real work when it resumes. I wish I had a way to precisely quantify this, but I don't. Parrot (the Perl 6 VM) is going down the mark and sweep path, as well.
Speaking of locality, another problem in Java (or C# / .Net) is local variables. Everything other than simple numbers and booleans is a reference to an object on the heap. It seems that there is no such thing as a local variable, effectively, in these languages where everthing is a reference to an object. It might be nice to have modest size buffers on the stack, as in the old days of C and Pascal.
So what would I like to do or have?
The short answer is: A hybrid of Perl and Turbo Pascal (sorry, Ruby).
Here are features that I think would be interesting:
Maybe carping about the speed of any language is mostly moot now-a-days, since we are all just waiting for the database anyway. Perhaps that is a topic to attack on another day.
Lest I forget to mention aspect oriented programming, I am leaving out aspect oriented programming (as one would mention an unpopular cousin in a will, so as not to have it contested). Maybe I am just too much of a Blub programmer. Or perhaps the aspect oriented Java tools solve Java problems, and it is less of an itch to be scratched in other languages where you could make ad-hoc chains of blocks / routines to be run as the need arose?
And what's so new about mark and sweep garbage collection anyway? Lisp has been doing this for a long time.
Lately, I have been busy with some things at work, which I can't talk about, so I have not written much. Suffice it to say, I still get paid to work with Java in its various facets and frameworks. However, I hope to be writing more soon.
(note that there were no entries for May and June)