Byzantine Reality

Searching for Byzantine failures in the world around us

The Perennial Java Problem

The hypothetical “good programmer” should learn a new programming language every year in order to keep up with the latest and greatest in the programming world and keep their brains nice and fresh. This is of course old news to anyone who has read The Pragmatic Programmer and similar works but it doesn’t hurt to bring it up every once in a while! When working on AppScale I got to learn Ruby and was infinitely happier for doing so, and while AppScale also uses Python I don’t feel as though it’s sufficiently different to justify calling that my language for this year. So with that said, I investigated what I will politely refer to as “the Perennial Java Problem”:

The Perennial Java Problem: Find a programming language that sucks less than Java but can still be used for real work.

If you are a programmer who has used Java, you likely already know what I’m talking about: Java is great but has some serious shortcomings. For starters, using Java without Eclipse or NetBeans is a death wish. This is already lethal for a person like me, who had fallen into the “vi/emacs or GTFO” mentality. Disagree with me? Try programming the sample apps for the Android without Eclipse. I tried it, succeeded, and learned a lot for my trouble, but it’s truly a second-rate experience compared to using Eclipse to do the same job. So why do you need Eclipse for this? Because (insert drum roll sound here) Java is ridiculously verbose. I know, you already knew that. But the sheer complexity of the jobs Java now supports means that you can BE A BIG MAN and use vim and ant and the COMMAND LINE to take an hour to run the first iteration of a note pad application on the Android or you can spend five minutes doing it in Eclipse. Sheer pragmatism demands that you break out of the “vi/emacs or GTFO” mindset if you want to program in certain languages.

As far as I’m concerned, Ruby solves the Perennial Java Problem for me well enough – it is simple enough that I can actually use vim to program in it and not regret the decision until the day I die. It can do the things I actually need to do to get work done with extreme ease – read and write files in less than a dozen lines of code, write a web application that I can actually use in an hour, and the inevitable “throwaway scripts” that Ruby excels at that are just enough of a pain in the ass that I can’t use Python or Java for. Granted, I still give the fantastically worthless award of “best web framework” to Python Google App Engine’s webapp, since it truly embodies the spirit of you have work to do so I’m doing to make this as simple as possible for you. However, reading/writing files and shell scripting is still a pain in Python compared to Ruby (To the Pythonistas out there: it’s not that bad – it’s just not as easy as Ruby).

So why don’t I just go get married to the Ruby programming language then, since I’m obviously so in love with it? Well, although I obviously love Ruby, there still is the whole “learn a programming language a year or your brain will rot and you will do is think Ruby until the day you die” issue. This nicely brings us back to the (modified) Perennial Java Program:

The Perennial Java Problem: Find a programming language that you don’t already know that sucks less than Java but can still be used for real work.

Historically speaking, the latest and greatest programming techniques are inevitably stolen from functional programming languages (e.g., garbage collection, dynamic typing), so why not just cut out the middleman and learn a functional programming language? Well it’s because of that last bit of the problem: the language needs to be one that I can do real work in. And the experience for me with a functional programming language is always very similar to the following:

  1. Invention: The Gods of Functional Programming have bestowed upon us mere mortals a new functional programming language, X.
  2. Sales Pitch: This language can compute a lazy infinite set of integers IN ONE LINE IN PARALLEL OMG
  3. Sold: I immediately decide that this language is amazing and all others are immediately inferior
  4. Disappointment: I can’t figure out how to read or write a file in less than a dozen lines without breaking all the fundamental concepts the language holds dear to its heart.
  5. Depression: I return to the previous programming language I was using and am unable to bring back anything profound from the functional programming world to it.

Part of the reason that functional programming languages haven’t clicked with me is points (3) and (4) – I’ve decided to use this language for everything and maybe I shouldn’t. This is partially my fault: it’s easy to say X is great for this so let’s use it for everything. For Ruby this works fine most of the time but for Java not so much (specifically with respect to shell scripting). When approaching functional programming languages I (perhaps mistakenly) approach them with the mindset of how is this an improvement over what I’m using now? And since they (perhaps naturally) fall short on the things that I need to do for my work, maybe I’m setting myself up for failure with them.

Let’s then look at a (relatively) new programming language and examine exactly what problems it solves: X10. It’s one of the many “runs on JVM” languages but has the following features that I find particularly interesting:

  • First-class functions and anonymous functions – functions can be passed around to other functions, stored in variables, or not if you don’t want to.
  • Domain specific: It aims to solve the problem of writing concurrent applications – so it doesn’t aim to replace Ruby/Python for your shell scripting and web app needs, but bills itself as the language to use when you have some serious computation to do.
  • Compiles to Java bytecode for serial execution mode or (more interestingly) to C to be deployed over MPI
  • If compiling to Java bytecode, can interact with Java code
  • Looks very much like what UPC was for C – adding simple but powerful PGAS abstractions

The second point is the crucial one from what we’ve been talking about here: it aims to do concurrent / distributed programming very well and not so much of anything else. This is fine by me, as I can still stick by my favorite Ruby for all other tasks and use X10 for the tougher work. Furthermore, its Java interoperability is a nice touch should I really happen to need something from Java-land (although I can’t think off the top of my head what I would need in this programming domain).

Will X10 “suck less than Java for doing real work”? Time will tell. But initial hopes are high – the Eclipse integration is very nicely done and the documentation in there is extremely helpful. And while X10 looks like it will be a “need to use an IDE” language, that’s fine by me as long as it gets the job done.