As I start to publish more articles with content on [From Java to Ruby](http://www.amazon.com/gp/product/0976694093/002-9438203-3647224?v=glance&n=283155), I’ve started to get the usual resistance. Most arguments come down to the same general question: why would you ever tear down that existing Java foundation, with more than enough tools, libraries, programmers, commercial support, and experience? I mean, giving up IDEA would be like giving up my knife for airplane dinners after 911, so now I can’t saw through a wet noodle without generating enough smoke to make my eyes water.
So I could offer one counterpoint. Maybe you don’t want to tear down that existing foundation. Maybe you want an integration play, with JRuby, or ReST on Rails. And that integration play is powerful. But sometimes, you do want to start fresh, for a new project or a rewrite of an old one. Sometimes, there are good reasons to do so. And what can you say? Adopting a new language is hard. You do have to rip out a pretty good chunk of that old foundation.
Rebasing
====
I’m getting about halfway through my marathon training. I’ll run a half marathon in two days. I’ve been told to ignore my time the first time through. I need to set a personal best before I dare to try to improve. But once I’m done, if I want to run another marathon in a significantly shorter time, I need to peel back that foundation—my long runs—back to a very short run, and build up again from scratch, with a better time.
Our industry recognizes the cost of ripping out foundations. We don’t do it very often. Actually, we start from scratch, with a new programming language, every ten years or so. And we do so for many reasons:
- we’ve forgotten the pain
- we’re looking for something new that the old language can’t provide
- and we’re looking for a new start on a fresher, cleaner foundation.
For Java, the cleaner foundation involved better portability, a fresh look at distributed systems (Internet over CORBA or DCE), an interpreted version of object oriented programming, a superior distribution model (first via applets, but later via servlets)…
but we gave up something too. Java wasn’t as fast, it didn’t have the libraries C did, and we had not accumulated the experience that C++ developers had.
Pain
====
Sometimes, I get significant criticism because I don’t always recognize pain. Let me be clear. I do recognize the pain inherent in adopting a new language. There’s risk. You can’t rely on the set of libraries available in Java or .NET. It’s harder to find developers. The commercial investment is not nearly as strong. I get that. I really do. I just think that you can find the arguments for pain in hundreds of places.
But there’s another side to the pain. We’re only beginning to hear the pain of building applications with Java. As the complexity increases, and as the classic development model around the Internet changes with more Ajax and ReST over WS* for many applications, the pain with Java development is also increasing. So you’ll want to use Java in those situations where you can offset the pain with gain:
- you can offset the additional typing caused by Java’s typing with the benefits of strong typing
- you can put up with additional complexity in the language because you can take advantage of the complex library support for security, distributed transactions, hard-core object relational mapping
- you can put up with the added expense of training Java developers because you can leverage the training expenses you’ve already made, or take advantage of developers that have already been trained by others.
In short, if I’m going to suggest Java to an account, I need to be sure that I will have a payoff for the pain. I’m suggesting Java to customers that have hardcore Enterprise problems, where Java’s benefits would offset the pain.
The bottom line
===
If I decide to run a second marathon, I’ll peel my long runs way back—probably to three or four miles. I’ll want to run a sustainable time that’s two minutes faster. I’ll then build that up slowly, over many months. I suggest Rails for greenfield database-backed web applications because I’m confident that the pain is worth the price. Ruby on Rails is not one-size-fits-all, but if I apply the tool to the right problem, the cleaner, simpler foundation will help me run more efficiently—to code more productively. Many features make this true. Some are related to philosophy, and many are related to the language behind Rails.
But we have more foundation to lay. We need to understand:
- How well Rails can scale. We have not pushed Rails as hard as it will one day be pushed. We need to know where the limits are.
- How Rails will integrate with the rest of the world. Some key questions to me relate to composite keys and low-level Java integration. iBATIS for Ruby will help; the Simply Crud stuff will help too, but there’s still some heavy lifting to do.
- How well will Rails hold up to years of maintenance? At some point, backward compatibility will start to matter more.
I’m convinced that this foundation will continue to grow and expand. There are simply too many good developers working on important problems in this space. For now, I’m content in the knowledge that yes—there’s pain. But there’s promise beyond the pain.