You’ve doubtlessly imagined that after a nuclear war, you won’t find anything except twinkies and cockroaches. I’m pretty sure the person who wrote that has never heard of COBOL. But no language keeps its leadership position forever, and Java’s not immune to bloat or decline. I’ve been convinced for a while now that we’re looking for a new language. From Java to Ruby is at the printers. This article is part of a series that will look at moving from Java to Ruby from several different perspectives. This perspective is the industry view.
Three things
====
Any language needs at least three things to emerge:
- A reason. Some sort of pain must motivate us.
- A connection to the past. Languages need communities, and communities need something familiar.
- A catalyst. Increasingly, the killer app has formed the nucleus of any new language.
You can (and doubtlessly will) argue with me about this list, but the idea is fundamentally sound. We won’t adopt a new language just for the hell of it, and we won’t move en masse until others are likely to move with us. This phenomenon is just one instance of crossing the chasm. Fundamentally, the emergence of a new language is a social event. If the best technology always won, you’d be reading this blog on OS/2 instead of Windows while you took in your latest Betamax video. Or even OS x. But the best technology doesn’t always win, and Lisp and Smalltalk are going to have to wait another 10 years, at least.
The reason
==
My reason for moving is simple. Java’s gotten too bloated, and isn’t the best tool for solving the problems that are most important to me any more. You can argue about what’s enterprise or not, but I’ve got a counter. I’d guess that over half of the applications we build are simple database-backed web applications. Java sucks at building them; Rails doesn’t. But I’ll go one step further. Java’s not really approachable anymore. It’s too hard to break into Java. I mean, go learn servlets, JSP, JSTL, Spring, Hibernate, JDBC, XML, Schema, Namespace, JSF, Eclipse, Ant and Maven and come back in four months so we can write hello, persistent, web-enabled world. And even then, we’d often write it wrong. It doesn’t stop with the frameworks. Some changes in the core language features are making Java more complicated and increasing the cost of entry for new developers.
And once you actually learn Java, the limitations don’t end there. You often need to type four times the lines of code to do the same job as a similar slice of Ruby code. Checked exceptions and all of the additional chatter around typing leads to more code to read, understand, and maintain. Java developers don’t have nearly as many tools to deal with the most promising techniques of the day: metaprogramming or domain-specific languages. The language isn’t dynamic enough. How do we respond? We bolt on frameworks to make Java more dynamic and delay binding. Spring, Seam, XML, AOP, annotations, byte code generation, and code generation all seek to work around Java limitations. Many of these frameworks are brilliant, and do exactly the right thing. But the point is that they have to do anything in the first place.
So Java frameworks are letting us down in the critical domain of simple application development. (I should point out that a couple of frameworks like Rife, JMatter, Wicket, and a few others are definitely moving in the right direction, toward simplification.) The Java language is finally letting us down, and has more bolt-on parts than Frankenstein. We can’t keep shooting up the language and our frameworks with Botox. Sooner or later, we’ll need a fresh start.
Java’s pain is undeniable.
A Connection to the Past
========
But having an excellent language with excellent frameworks is not enough. Seaside is a killer web development framework, maybe the best there is. But it’s not popular enough to attract enough community to make Seaside a viable option for my career or my customers. And in some ways, Smalltalk, Lisp and the functional languages, while productive, are perhaps too alien to make a dent in the mainstream. So they will remain the tools of choice for the chosen few. But give me a connection to the past, and I’ve got something familiar that I stand a chance of selling. C++ helped inch us closer to object orientation by dragging the C syntax, and full backward compatibility, right along with it. Java succeeded partially by grabbing the C++ community through sharing syntax and many idioms.
At the core, Ruby and Java share more than you might think. At the core, they are both object-oriented languages that run on an intermediate machine. Ruby’s is an interpreter, and Java’s is a virtual machine. Ruby shares a problem domain (in web development), a core set of tools like MySQL and Apache, and many common idioms. Ruby syntax is also close enough to Java’s to be somewhat familiar. It doesn’t feel as alien as a Lisp, Haskell or Smalltalk might.
Ruby has a connection to the past.
A Catalyst
==
In Crossing the Chasm, Moore makes the case that it’s relatively easy to establish early adopters for a decent technology. Your task gets a little tougher when you try to ramp up en masse. Getting the initial wave of pragmatists, who often need to see evidence of mass adoption, makes establishing a new language especially problematic. That’s why you see popular languages explode onto the scene, or stagnate. You need at least one killer app to start ramping up. With C, Unix was the catalyst. Perl had CGI. Basic had Visual Basic and Windows. Java specifically had Netscape and applets.
Ruby has Rails.
A Blank Slate
=====
What would you do if you could rebuild Java from a blank slate? Would you reconsider using XML tasks with Ant? Would you revisit the class loader? Would you relax the typing model in some places, or reinforce it in others? Would you maintain checked exceptions at all costs? Would you include true generics, or continuations, or closures? How about delayed binding? Would you bake in AOP?
The truth is that we do occasionally need those forrest fires that scour the forrest, burning the deadwood and tangled overgrowth to allow a fresh start. The thing is, it’s hard to plan the burning. If you’ve ever seen a clearcut forrest replanted with pine, then you get my metaphor. The new “forrest” has no more life or vitality than a corn field. A true fresh start takes exceptional planning and touch, or mother nature. Some get excited about the new forrest as new trees begin to grow. Others will wait until the trees are a little mature.
Programming languages need fresh starts too. Bad decisions are sometimes hard to unmake. Bolt-ons invariably trade short-term gain for long-term pain. And sometimes, we just learn something important. Like, XML configuration is not always the answer. Or, continuations are useful to someone other than my programming languages professor.
Moving forward
======
I’m not here to argue that Ruby is the next Java, or that Ruby can do everything that Java can. I’ll not soon be recommending Ruby for applications requiring hardcore ORM, or two phased commit, or intense enterprise integration. I’m merely saying that Java has some serious problems in some spaces, and Ruby has some of the answers. I’m also arguing that conditions are ripe for alternatives to emerge. Dominant languages tend to come around every ten years or so…
- early 1950s: COBOL
- early 1960s: Fortran
- 1970s: C
- Mid 1980s: C++
- 1996: Java
- 2006?