Forum OpenACS Q&A: Response to A Technical Paper on Java

Collapse
Posted by Todd Gillespie on
Fantastic paper, Ben! It concisely enumerates the reasons that I have been struggling to explain to clients and collegues. If there is anything I could contribute, it would be:

Java OO vs RDBMS: I would relate more concrete figures in this section. There is much to be said on how OO can break JOIN semantics, but on a related subject is how the predilection of most app servers to attempt to abstract away the RDBMS makes programmers unaware of RDBMS performance. PhilG related, in one of his recent one-day courses, that an in-memory object can be updated a few hundred million times per second, but a RDBMS can only issue a few hundred COMMITs to disk every second under optimal conditions. The naive Java programmer, using an abstraction best titled 'magical persistence', can see a 6-order of magnitude drop in expected performance. I've stopped counting the number of systems that take this approach.

I have always thought the most attractive technical thing about the ACS is how close it stays to the database (acting very like a responsible DP application). The authoritative location of data is never in dispute, and flow of control is relatively easy to follow (even with nsd filters in the way). IMOH, the ACS avoided lots of sophmoric design mistakes, eg, trying to outsmart the DB, which just turns into a nightmare trying to debug your cache.

None of this is explicitly against Java, except that:

Strong static typing makes SQL a PITA: any ad-hoc SQL querying in Java is burdened under layers of code casting vars to string and constructing strings. There is no concept of string interpolation nor of automatic casting. Fetching results is equally difficult due to its inflexibilty: I just recently dealt with a system wherein the developers assigned any numeric query values to java integers....eventually they wondered why all financial records were rounded to the nearest dollar... The combination of difficulties on both input and output of RDBMSes naturally tends to encourage abstracting away the DB, leading to the evils proclaimed above and in Ben's draft.

Strong static typing is a boon when a module has predefined functionality (no lambda), certain garantees on inputs, and a large amount of complex operations on internal data. The provided invariance enhances stability on such problem domains. But when working with large amounts of foreign data of varying structure and content, the restrictions are a major disadvantage. In web applications, Java objects are best keep, much like monads in Haskell, kept in a closet out of the way of primary execution.

I hope someone here can express that with more clarity than I have.

My pet peeve is that Java is just the incremental language upgrade to IT departments the world over that we see every 7 years or so. Perhaps my rancor is getting away from me, but it seems like the industry tries to spoon-feed new language developments to its customers; and for what? so as not to scare them? to ensure future revenue? laziness on everyone's part?
But the majority of the above named '2 million' Java developers have never been exposed to first-class functions, ML typing, Sather iterators, the arch-god LISP, the sheer coolness of Ruby (best described as a cross between Smalltalk, Perl, and Kick-Ass), etc, etc. What I would like to know is how to relate to managers and programmers everywhere that it is safe to move into the present.

This thing, that hath a code and not a core,
Hath set acquaintance where might be affections,
And nothing now
Disturbeth his reflections.     -- Ezra Pound, "An Object"