Previously posted on Lacrymology.com

On Java^TM (part 1)

I’ll start immediately by saying that I am in love with Java^TM. It has provided me with a constant source of Long Island Iced Tea funding, as well as helping to pay the rent (in order of importance). However, as a self-proclaimed hacker (although these days a bit of cruft is forming on the keyboard), something about Java^TM just does not smell quite right. It wasn’t always this way. Java^TM once smelled like money, and to a fresh-out-of-college stud like myself, money was the only smell worth smelling. As the time has passed and I am starting to make my bones (although I am closer to gelatinous goo than vertebrae), Java^TM has lost it’s original fragrance and has started me reminiscing on $20 whores. This should come as no surprise however, for had I read the original whitepaper by James Gosling, I would have observed one
of the primary guiding principles:

The system that emerged to meet these needs is simple, so it can be easily programmed by most
developers…

After a few years of hard-core Java^TM development, I have come to learn that the previous sentence has almost universally been translated as:

The system that emerged to meet these needs is simple, so it can be understood (sic) by
managers and facilitate Mongolian Horde programming methodologies.

What on earth am I talking about? First of all, Java^TM is specifically designed to allow non-programmers to become programmers. The success of this goal can be debated all night long, and I tend to believe that it has failed. Programmers are not the product of simple languages that treat them like idiots. Java^TM code written by an ape will always look, feel, and operate horribly. The simplification of the language will not compensate for lack of skill. Likewise, the fact that Java^TM intentionally adopted a C++ syntax in order to facilitate familiarity for C++ developers willing (most likely forced) to make a change in languages. On the surface, this property may seem virtuous in that it presumably allows C++ hackers to make a smooth transition to Java. Sadly, anyone who has spent any appreciable amount of time surrounded by programming geniuses will see the sham perpetrated by the C++ style syntax choice. That is, expert-level C++ programmers care nothing for the stag of C++. These people are C++ hackers because they know how to think programmaticaly. These people can speak in binary, and perform math in base-8. These people couldn’t give a toss about language syntax, and in fact often see it at worst a nuisance and at best charming. C++ hackers would not lose a step in productivity regardless of the syntactical choice, be it C++, Scheme, or Logo. Given the choice between someone that truly grasps the nuances of programming in Lisp over some code-grinder familiar with C++ syntax; the former wins 100% of the time.

Second, during my extremely limited time working in the "real world" I have been assaulted with the supposed power of Java^TM to support Rapid Application Development (RAD). Granted, I have been able to whip up some massive functionality quickly in the name of creeping-featurism, therefore the RAD aspects of Java^TM have largely succeeded. Having said that; RAD is BAD. I cannot count the number of times that a crafty mock-up has fooled the customer in question into believing that the desired system (which they very often than not have no clear picture of… more on this later) is ready to be signed, sealed, and delivered. This perception has been the cause of innumerable amounts of ill will toward developers:

Customer/Manager: Why is it taking so long to deliver my program? You were 90% done 6 months ago!

Developer:
Uhhh. That was a mock-up

cue crickets

Customer/Manager:
Why is it taking so long to deliver my program? You were 90% done 6 months ago!

Stay tuned for part two.
-m