Itâ€™s way too early in the morning, but the kids are tearing down the stairs, and making more noise than my aching head should tolerate. But itâ€™s Christmas, so I do. They are drawn to the biggest, flashiest, plastic toys first, but my wife and I share a knowing smile. That will change.
Iâ€™ve got a little kid inside me, but not when it comes to Java tools and frameworks. It takes a lot to get me to adopt a new framework. But sometimes, when friends that I trust are playing with something, Iâ€™ll pick it up too. Erik Hatcher, Stuart Halloway and Dave Thomas are very good at distilling the buzz, and separating out whatâ€™s important. So I decided to give Ruby on Rails a try. Rails founder David Heinemeier Hansson claims gaudy, plastic-like 10x productivity gains over Java. Iâ€™ve been skeptical, and Iâ€™m not alone.
Around 1:00 PM, the first toy breaks, and the joyous laughter turns into heart-wrenching doom. After a little comfort and a lot of psychology, we get the kids to move onto something else. In truth, not many toys will survive the first couple of months after Christmas.
David Geary summed up the feelings of the Java community nicely. Rails may be productive out of the gate. But itâ€™s sure to wither under the load of enterprise development. After all, Rails has a few obvious flaws: domain objects must inherit from a common persistent base class, the templating technology does look a whole like the embedded Java that failed for this community, and Ruby is probably not as fast as Java. Further, early in the Rails development process, developers rely heavily on scaffolding to get things off of the ground quickly. That might lead to immediate productivity, but the gains will surely dwindle over time as the scaffolding is replaced.
After a couple of months beyond Christmas, the best toys emerge. They are built to last, and have enough flexibility to keep up with the active and fickle imagination of a kid.
But I love Ruby. And I think Rails has potential. The experience starts when I want to download Rails and add it to my Ruby installation. I type â€œgem install rails.â€ And thatâ€™s it. Ruby goes and gets the latest installation, and also pulls down the dependencies that I need. Very slick. Next, I want to get plugged into Rails best practices. I want to use the right directory structure, and build the first sample applications in the right way. I read a little bit, and then type â€œrails messagesâ€ to create my application structure. Similarly, I can generate and scaffold a basic application, with model, view and controller layers, to do the basic CRUD operations on a database. The process takes 15 minutes. Thereâ€™s no setup for the web server. I donâ€™t need to live with the scaffolding until the end of time, but I generally find that Iâ€™ll use some of the scaffolding methods with very little change. Iâ€™ve not used Rails for a production application yet, but I can imagine that it would let me get a simple user interface flow in front of my customer in a hurry. For that reason, I used to build â€œugly pagesâ€ which could later be customized by a designer. So, immediately, thereâ€™s a lot to like. But is it a toy?
Invariably, a relative will give a movie or toy to my kids that I just donâ€™t want in the house. I donâ€™t like Barney, or Barbie, and never have. My girls have quit asking for them. Wonâ€™t work. So Iâ€™m a jerk, but a happy jerk.
So hereâ€™s the rub. Is Ruby a toy? And if not, is it fundamentally sound? Many rapid development environments break down because they might provide more productivity than their basic languages, but they also limit the power of the language. VisualBasic is famous for letting you build the first 80% of an application quickly. Itâ€™s that last 20% that will kill you.
I donâ€™t think Rails will suffer from this problem, to the same degree. You can completely replace the view, controller and model layers for Rails. The difference between Rails and alternatives is that you can live within the scaffolding in the mean time, and then iteratively adopt it for your use. There are things that will keep me from using Rails on some projects. Most of them have to do with limiting technology for a given problem, like the lack of OR mapping for an existing schema. (I think Hibernate and Kodo JDO both kill ActiveRecord if the schema doesnâ€™t match the model, or if the two are expected to evolve independently.) I donâ€™t think that the Rails developers have completely thought through the visual component architecture, in a way that say Tapestry developers have for layered user interfaces.
In fact, the best â€œtoysâ€ often turn out not to be, well, toys. One kid loves her necklace, and the other loves her mountain bike. Big and beautiful books are often hits. To survive the first couple of months, a toy must be good. It usually is beautiful, simple, and has a little bit of magic to it.
Which brings me back to Ruby on Rails. Itâ€™s got that magic. Iâ€™ll just give you a little taste. When youâ€™re mapping a Java class to a schema, you must often type the name of a property five times. !!!FIVE TIMES!!! Count them. Three in the bean: the getter, the setter, the instance variable. One in the schema: the field. Two in the mapping: the property, and the column. In Ruby, you type it once. Reflection and inspection of the database handle the rest. You use intelligent defaults and naming conventions to handle the rest. You can always override differences, but you donâ€™t have to. Or take the mark up tags. They look like Ruby. Heck, they are ruby. That beats the scripting that we usually put into HTML, in the form of JSP tags.
So Iâ€™m not completely convinced, but I do think thereâ€™s something here. Iâ€™ll certainly try to get paid to do Ruby in the near future. But I do think that Ruby has the magic that great solutions have. And I think that part of that magic will never translate to Java.
My kid looks into the toy box. Will she reach for the toy that she got a few short months ago, over Christmas? I really donâ€™t care. It depends purely on the game that she wants to play.
And thatâ€™s where Java developers often come up short. Weâ€™ve got a golden hammer. Itâ€™s the ultimate golden hammer. Itâ€™s the programming language itself. Iâ€™m not going to pretend that anyone would ever use Rails for everything. But think of the number of applications that you build that do nothing but put a big web front end on top of a persistent model. Thatâ€™s a huge part of what we do. If Ruby and Rails can make you that much more productive, and if it solves the problem, why wouldnâ€™t you?