or learn more

On Java

Oct 27, 2003

Previously posted on

On JavaTM (part 1)

I’ll start immediately by saying that I am in love with JavaTM. 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 JavaTM just does not smell quite right. It wasn’t always this way. JavaTM 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), JavaTM 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

After a few years of hard-core JavaTM 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, JavaTM 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. JavaTM 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 JavaTM 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 JavaTM 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 JavaTM 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!

Uhhh. That was a mock-up

cue crickets

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

Stay tuned for part two.

No Comments, Comment or Ping

Reply to “On Java”