I’ve always been of the opinion that Java was kinda ugly, kinda kludgey, but a decent general-purpose language. Like most, I felt that the large framework that comes standard with Java, together with the many developer tools written to help you write Java code, really outweighed any of the minor inherent language issues and implementation issues. Well, now I’ve changed my mind. I’ve decided that now, I really, really dislike Java. In fact, if it were possible, I would piss on Java and set it on fire (is that possible? does urine burn? is that a hate crime?). I’ve just had enough.
Our story begins with my roommate, Matty, and I beginning work on our Honors capstone project. We are required to take a class, Intro to CS Research (2 credits), and do a quarter’s worth of independent study-type work (again, 2 credits) for our final requirements to attain that ever-so-prized honors diploma (sarcasm intended). Since Java is the language where we, as a team, feel the most comfortable, we began our work. It didn’t take very long to run into quite a few hurdles.
(To digress a bit, my war with Java has been ongoing for about four years. As you could probably glean from the many other rantings on this blog, nothing annoys me more than fanatics, and Java has more than its share. Also, that whole “Write once, run anywhere” sounds cute and all, but rarely works in practice (mostly from my experience working with AxionDB and RMI in Database Systems Implementation). Well, back to the real story.)
The first thing I ran up against, courtesy my limited experience in developing GUI applications, is a desire to make a nicely organized Model-View-Controller (MVC) type design for the GUI parts. To do this easily, efficiently, and not-ugly-like, it’s most helpful to have the links of the View receiving the Model in the form of an observable model. If your collections are observable, your GUI code simply has to register for change events from the collection and update itself whenever something happens. This means that:
- Multiple view components can listen to the same collection for changes without duplicating logic
- Listening for events is really simple (once the framework is in place)
- Events can be sent out asynchronously, thus not blocking any piece of your code while updates are being made
- You can register for exactly the types of changes you want, and update more efficiently (e.g. on item removal, just remove the item instead of refreshing the entire collection’s view)
- Adding listening components adds only linear complexity (in terms of both writing code and efficiency)
- Pushing out data rather than polling is (near) always the desired path, since there is always less latency and less communication required
Java, in all of its gigantic-all-purpose framework-y goodness, does not have observable collections. Since I figured that there was probably a good reason for this, I went to everyone’s favorite research tool and searched for “java observable collections”. Turns out that Sun has a response to this very question, which you can find here (Why don’t you provide observable collections?) Answer:
Primarily, resource constraints. If we’re going to commit to such an API, it has to be something that works for everyone, that we can live with for the long haul. We may provide such a facility some day. In the meantime, it’s not difficult to implement such a facility on top of the public APIs.
Sounds like a pretty big cop-out to me. As with most things, a simple, general solution provided that works for most people most of the time is generally what frameworks are for. I’m not sure what resource constraints they are talking about, but this can’t be realistic. If they are talking about time, people, or complexity, then they certainly debunk that with the last part of the answer (”it’s not difficult….”), and if they are talking about the inefficiencies of having that in the collection, I think they are full of shit. The collections themselves are general solutions that work most of the time for most people – I imagine if you need incredibly efficient (size or speed) collections you are going to write them yourself, or use a language that gives you more control over your representation on the system.
(Another sad side-note: the .NET framework has observable collections, and it makes GUI programming really friggin easy. You create a control and tell it the collection to listen to. You don’t even have to modify the GUI controls to be aware of observable collections, it just works.)
So I ended up writing my own (tiny) framework for observable collections (that is basically a thin wrapper on regular collections), plus an implementation for an ObesrvableList (again, a really thin wrapper on top of ArrayList). So far, it has made coding the project incredibly easier. In fact, I’m quite convinced that creating a good, logical, efficient, and simple separation between view and model (without making the controller into some monolithic piece of pure code bloat) requires you to use some event-oriented programming, although I doubt that is the real term.
The other issues I run up against are far more abstract. When I write Java code, I feel like I type 6 words for every word that actually does something. One of the reasons for this is not having first-class functions (functions that I can pass as arguments), or having anonymous functions or lambdas. When I want to create an anonymous listener, say, or Thread, or any type of tiny logic that you do all the time in Java, I have to write an extra 3-4 lines of code for non-functional syntax to make the thing into a class. “But lo!” you say, “is not the first-class function mere syntactic-sugar?” To this I simply state that of course you can accomplish the same thing regardless, but its a matter of growth of complexity. Steve Yegge has a much more complete and better written article about languages (one of many) where he says:
If Java code bases grow superlinearly with the functionality, and Perl/Python/Ruby grow roughly linearly, then Lisp grows sublinearly.
The point, and where Steve and I agree (albeit my much less experience/intelligence vs. the Steve Yegge), is that Java just does not scale as a language. You end up writing a whole lot of fluff for a little bit of bang at the end. The reasons why it can be a useful tool, memory management, anonymous classes, JVM, framework, etc., are far outweighed by the fact that it will never scale in any realistic sense. You will always write much more code that is non-functional than you will write functional, actually-does-something code. If you don’t believe me, go look at your most recent piece of Java code. I’ll even give you the benefit of ignoring all comments. How many lines of code or pieces of code actually do something? How much of your code is dedicated to masturbating the type system just enough so that it doesn’t yell at you (yes, even with generics in 1.5)? How much of your code is getters/setters?
You should really stop reading my blog and go read Steve’s old blog, Stevey’s Drunken Blog Rants. It will make you a much better programming, I promise you. His new stuff from Google is kinda weak, but his old stuff from Amazon is gold. He gets three thumbs up from me (use your imagination). Go read. Now.
If you haven’t gone yet, perhaps you are wondering about the strange title. I considered at the onset titling this “java: 0, noah: 1″, but I figure that I don’t really win anything for identifying how much Java annoys me, since I still am writing in it. I considered “java: 1, noah: 0″, since Java seems to kick my ass, time and time again, by letting me down in incredibly annoying ways, but that doesn’t make Java a winner. So I settled on what it is now, “java: 0, noah: -1″. We’re both losers, Java and I, but at least it has more mindless followers.