[geeks] Java as a first language

[Jonathan C. Patschke]

On Fri, 10 Nov 2006, Robert Brooke Gravitt wrote:

> Please. I second this. The world does not need YABJP [0].

If I could cash all the ones I've experienced in my short career at a
dime each, I could probably retire already.

I don't know what it is about Java (probably the complete isolation from
resource management), but folks who only know Java seem to be among the
worst programmers on the planet.  The only-VBers are bad, too, but VB
has a practical limit to how many different boxes you can stack inside
each other to create The Ultimate Kludge.

> I've been involved in several different kinds of development, from
> writing the device drivers for a PCMCIA USB HBA to several C/C++
> billing systems for major telecoms, and many, many, many J2EE gigs.

J2EE gigs just make me want to scream and tear my hair out.

J2EE can -probably- be done well.  I've written a couple small servlets,
and they're about as much fun to write as CGIs, only without all the
environment mangling.  They're not horrible.

But, again, J2EE lends itself to the sort of thinking where, rather than
writing simple code, you go out and buy "components" that don't quite
fit in to the application and then spend forever trying to write a shim
in-between them.

I have a great story about that from my previous employer.  I was
employed as a system analyst (mostly AIX and BSD and Solaris
administration with some programming tossed in as needed), and was
supporting a doomed project to move the employer's operations off of a
customised COTS application running on MVS to an in-house application to
run on a pornographically obscene amount of AIX systems[1].

This particular day, we were tackling document management.

The database already had all the metadata for each and every document;
we just needed to store graphic images of the documents somewhere and be
able to reference them quickly.  They asked my opinion, and I said that
we should get a pile of fast redundant disk, split it up into multiple
filesystems, create a hierarchy of directories in those filesystem,
assign each document an incremental serial number, and hash that serial
number into a path component to spread the load across multiple name
spaces and spindles.  We'd need to evaluate several hash functions to
determine which one gave us a the best directory-search times on JFS2 as
the number of files got Large, but the framework would take a day to get
into place at most.  I got a non-committal response and went back to
working on whatever else I was doing at the time.

A couple weeks later, a gigantic box of software shows up on my desk
labeled "IBM Content Manager for Multiplatforms".  It was ONE HUNDRED
AND FIVE compact discs.  This was the "component" they were going to use
essentially just to map files to DB entries.

After two months and three contractors, they almost had the software
installed and working.  Eight months later, they almost had the software
integrated into the rest of the application.  They had four full-time
programmers working just on integrating this behemoth into the rest of
their J2EE crap.  We had to buy five more POWER4+ systems to support
Content Manager as they were using it.  They had to buy three times as
much disk as originally planned because Content Manager stores the
-documents- inside of DB/2, rather than in separate files.

I came to find out after the fact that IBM told $employer not to buy
Content Manager.  It was, far and away, the wrong tool for the job,
since we already had our metadata in-hand, and IBM didn't want to come
away with a black eye on a potentially high-profile project.  Now, if
you've ever dealt with IBM sales, you know that when the IBM salesdroid
says "please, Mr. Customer, don't buy our product," it's going to be a
trainwreck to remember if you actually do try to implement it.

> GC is like magic to them. We have to recycle apps daily because some
> geniuses can't figure out how to manage their damn objects.

Oh hell yes.  Not only that, but they don't realize that objects aren't
as "cheap" as they seem, especially if they have a significant amount of
state attached (like, say, the result of a database query).  So your
application's performance is split between spinning the GC thread
looking for free heap thanks to folks who let objects linger about
forever and constantly creating and trashing expensive short-lived
objects.

Therein lies the rub: even in programming languages where you don't
manage resources directly, you STILL need to manage your resources.

> I think Perl is a good place to start.

I'd have to agree.  So long as you remember "use warnings; use strict;"
it's very possible to write good code in Perl, and it's an easy language
to get running in very quickly.


[0] NMF
[1] The idea was to move off the mainframe because it was expensive to
     lease.  For what they spent on AIX hardware, they could have
     -BOUGHT- a new zSeries system.  For what they paid to develop the
     doomed project, they could've paid for decades of maintenance AND
     whatever porting was necessary to migrate from MVS to zOS.
-- 
Jonathan Patschke  ) "Some people grow out of the petty theft of
Elgin, TX         (   childhood.  Others grow up to be CEOs and
USA                )  politicians."              --Forrest Black