debunking the debunking bunk

If you write code for a living or a hobby, it has probably been difficult to ignore the oblique war between the various language camps, although the lines aren’t as clearcut as the “Java vs. C++” wars of old. Recent salvos instead seem to be between Java and scripting languages.

It occurs to me that this is a discussion about taste. Joyce pointed out to me that she doesn’t generally get the vibe that Perl/PHP/Python people ever diss the other’s language choices the way they do Java. My experience also bears this out. I would prefer to write in Python where I get the chance, but I don’t mind Perl or PHP, although I don’t think they fit my style as well. On the other hand, I generally dislike writing Java (despite having used it in everything from J2EE to J2ME environments). My personal aversion springs from a feeling that Java is very condescending about the constraints in puts on me and very unthoughtful in the hoops it makes me jump through to get up-and-running with it. Java (to me) is the victorian day-bed to Python/Perl/PHP’s Le Corbusier chaise. While I might prefer some other modern artist, I will take any of them any day over a baroque disaster like Java.

Whatever the reason for my unfounded aversion to the language, Java geeks seem to feel very strongly that they are being singled out for ridicule among the “cool kids”, and I will say that it’s not a sentiment without some basis in fact. Case in point is a “rebuttal” of sorts to some points that Java people seem to feel singled out by.

My problems with this article start with the title, “…Why People Think Java is Un-Cool – Debunked”. Frankly, your standing as “cool” or not is ONLY in the minds of “people”, so debunking their opinions with facts is useless. You might be able to change their minds, but you certainly won’t be able to proove coolness or lack thereof. Having been through the editorial process, though, I think we can safely attribute problems in the title to someone other than the author.

Which only leaves the rest of the article. I’ll go through the points one-by-one and give my off-the-cuff reactions to each. Note that I’m not unbiased, only experienced enough to have formed some of my own opinions (or stolen them from people smarter than myself).

  1. “Java Has Considerably Fewer Surprises”. If your basis of comparison is Perl, this point could be valid, but it doesn’t hold up to more than cursory scrutiny either way. Java’s surprises are myriad and maddening. What do you MEAN I can add two strings with the plus operator but I can’t define what that should mean for my own objects? You mean I have to manually munge paths to library files (in the invocation of a program!) myself? What kind of a two-bit language makes me write this much code just to OPEN A FRIGGING FILE AND GET A STRING? Java has plenty of surprises, and most of them are nasty. Asking that a programming platform do things like provide you with standard ways of placing things where they can be found by other programs isn’t an affront to anyone’s man/womanhood and it’s not lazy. It’s the point of computers: they’re supposed to do things FOR YOU.

    Oh, and for the record, I write Java, and I do NOT fail the “geek test”. That said, I almost never choose it unless there is some library support reason to do so.

  2. “Java is slow”. Wow. Where to begin? I could start with “contention on scarce resources and poor algorithm choice always dominate”, but I wonder if it would even matter. By this point, good java developers are already shaking their heads. The author likely hasn’t written any network services. Perhaps I should just move on.
  3. “Swing disasters continue”. Huh? Few enough people actually interact with SWING apps on a daily basis to know how badly they perform, and fewer still have to wade through the examples to write it. “Swing disasters” continue (IMO) because SWING requires too much of the developer for too little payoff. By the time the developer gets done initializing all his layouts, he’s gotta take an RSI break, and by the time his keyboard accelerators are hinted, it’s time to go home. This isn’t a brilliant API, it’s a borken API if I’ve ever seen one. Verbosity and capability do not brilliance make.

    I’ve written SWING apps, and I can honestly tell you that whenever I get the chance, I’d choose (D)HTML, PyGTK, PyQT, XUL, or even raw QT/C++ instead. For Java the choice would fall to SWT, and failing that AWT (which, of course, you need to know anyway to use SWING). Almost the only place where I’d choose SWING would be on an OS X box where it won’t look like a dog came in and spilled purple paint on my UI and then scratched it up (yes, yes, i know all about PLAF, it blows goats too).

    Java has had a serious advantage over other programming platforms for almost a decade in that it has shipped a capable, full-featured, and standard UI toolkit across multiple platforms (and it looked better than TCL/TK). This should have been its saving grace, but like so many things in Java, all of the bits of polish that separate a university experiment that escaped the lab from production software have been left un-buffed and the net result is overly-high ongoing cost and mental expense when investing in Java for developing applications. Technology decisions are investments, and being blind to the ongoing costs associated with that investment is something that’s indefensable when you aren’t paying the bills. So if you’re a Java developer, ask yourself this: are you really doing your employers any favors by discounting the mental cost and time-related effort involved in apologizing for all of Java’s little “quirks”? I’m not suggesting that you ditch Java, but I am suggesting that you come to the table with a fair understanding of where your tools are good and where they suck. The author of this article clearly did not.

  4. “Java is a strongly typed language…”. So let me get this right: the compiler tells me that I’m wrong, and then the unit tests tell me that I’m wrong (when I get them to run), and then my users tell me I’m wrong. Don’t the first 2 seems a little redunant? And if the unit tests can’t tell me that I’m wrong, how is type checking going to help me get my logic right here?

    You’ll excuse me if I show the chaperone the door. With a killall -9.

  5. “Java has a library…”. And here we get to why Java is really used everywhere and for so many different things: because there’s already so much Java code written that in a lot of places, you’d be an idiot not to use Java. It’s the reason I use ANT for building netWindows despite my revulsion of XML as a poor man’s Makefile. It’s the reason that I write Java for mobile devices when I want to hack something together for a phone (nevermind the atrocious build process), and it’s the reason that Java gets it’s grubby little hands into enterprise software. If you need to get something done, the odds are that there’s some Java code that already does most (or at least part) of what you need to do. This is why Java isn’t going away any time soon, and why I’ll continue to get jobs where I write Java. Java might not be the right language for the job, but it’s the only language with interfaces to all the tools you need to get a particular job done.
  6. “Java did not have a good IDE”. Says who? And why is that important? I still write most of my Java code in vim, which is the same thing I was using when I was learning on JDK 1.1. I’ve subsequently tried almost every Java IDE around (save IDEA, which I continue to hear great things about). I use none of them day-to-day. That might just say that I’m a horrible luddite (likely!), or it might be commentary on any language which needs tools with the complexity of a modern airliner to pull it out of it’s self-inflicted productivity death-spiral. You decide.
  7. “java is popular”…and therefore cannot be “cool”. I guess I don’t see the causal relationship here: the common cold is very uncool, while the plague is relatively rare but yet, somehow, not any cooler. TCL is less common than Python, but you can’t pay me enough to write TCL code. The law doesn’t hold.
  8. “Java isn’t good for drivers, low-level stuff”. Why? Why is any language inherently interpreted or compiled? I’ve done my fair share of byte array mangling in Java, and it’s arguably easier than it is in C. If what the author says about Java speed being near that of C these days, I fail to see the big hangup!?! The fact that you don’t have a good Java compiler that’ll let you talk to the metal isn’t Java’s fault, it’s Sun’s.

    Want to pin blame for why people perceive Java as a big, bloated, slow failure that’s hard to work with? Look no further than the company that begat Java, couldn’t figure out what to do with it, and then continually under-invested and then finally incorrectly-invested in it.

Now, before the hate mail starts pouring in, I’d just like to say that I use Java every day. I write Java regularly, and I really, really want Java to get better (if only because I want my life to suck less). I want Java to get better than Python. I want Java to support real closures and have lightweight userspace thread support on every platform that’s fast enough to beat Twisted Python. I want J2EE to stop giving java developers tools to shoot themselves in the foot with. I want Java’s APIs to be nimble and easy to understand. I want Java to stop being condescending and grumble inducing. I want Java to be a great language for the average programmer as well as the great programmer.

This isn’t the wishlist of someone who hates Java, this is the wishlist of someone that really believes that Java can get better. I also believe that as long as the Java commmunity is only going to excuse its many failures to deliver on what it sold the world, then it deserves a little tough love now and then.

Verbosity is not a virtue.
Performance is not a function of your language choice.
No language is inherently interpreted.
Java doesn’t have to suck.

2 Trackbacks

  1. […] Next was the less lauded, but arguably more important, Phobos. Think of it as an app-server for JavaScript. These apps can take advantage of the huge number of available Java APIs for doing most anything under the sun. FWIW, Jot takes much the same tack, but fixes the database layer impedance mismatch with a wonderful abstraction. Instead of imposing the amazingly painful “build, deploy, test” process that Java tools try to hide (and usually fail miserably), both Phobos and Jot acknowledge that the future belongs to dynamic languages. You might still hear lots of FUD out of the static languages camp about how interpreted and/or late-binding languages are tremendously slow, but the truth is usually that your language choice probably isn’t the bottleneck. […]

  2. By Continuing Intermittent Incoherency » Upgrade on June 13, 2006 at 6:50 am

    […] While the greenlet project looks like an interesting alternative to Twisted, it doesn’t look “baked” enough to handle most of the situations I’ll be relying on Twisted for. In much the same way that library depth is the only reason I keep inflicting Java on myself, protocol implementation breadth and depth are the reasons that Twisted probably has very long legs, despite the kludgyness of requiring factory classes every time you want to sneeze. […]