Comments on: Ruby on Rails and why code generation isn’t the bomb

By: Sam Newman

Sam Newman — Thu, 12 May 2005 08:47:59 +0000

Which was kind of the point of my post, but it did get lost in translation from my brain to blog :-)

By: Simon Willison

Simon Willison — Thu, 12 May 2005 06:56:14 +0000

I’ve seen a few people get hung up on the code generation aspect of Rails, but it really isn’t an important feature of the system. If you look at the code it generates (with the exception of scaffold) it’s literally only creating two or three line class definitions – it’s a bit like using an IDE which sets up your Java class definitions for you. Rails’ code generation is passive, not active, which means you are expected to fire it once and edit the code yourself from then on.

What makes Rails interesting (and exciting and productive and hype-worthy) is that it’s exceedingly well designed. I say this as someone who has experimented with pretty much every Python web framework out there – Rails is a extremely elegant, and solves the web problem in a much more natural way.

Forget about code generation: examine Rails based on the merits of the framework itself. You’ll almost certainly be impressed.

By: obie

obie — Tue, 10 May 2005 13:28:18 +0000

You are saying that Rails libraries are:

better/easier to use/more elegant than the Java alternatives because they are written in Ruby.

No controversy, man. It’s the truth.

By: Sam Newman

Sam Newman — Tue, 10 May 2005 09:11:14 +0000

(sorry about the problems with your comment not displaying – naughty MT).

The comparisons with AppFuse might be a little unfair, but I was focusing on the percieved benifit of the helper scripts, which as I said really isn’t the big deal. You then talk about how good the rails libraries are – I’m going to say something potentially controversial here – the only thing that makes Rails libraries better/easier to use/more elegant than the Java alternatives is the language itself, not the implementation. If Java had similar language features to Ruby, you’d have similar libraries – they’re all solving the same problems, and in the same way.

By: Bob

Bob — Mon, 09 May 2005 17:23:34 +0000

Rails, as you well know judging by the links on the side of the page, is more than a bit of code generation, it is accurately described as a “full-stack framework”. AppFuse is a “build file and directory structure” (the author’s description) that builds upon Erik Hatcher’s work in his Ant book.

Rails does do some code generation, yes, and it does set up your application such that it’s immediately ready for testing much like Appfuse. But you, as someone who has at least played with Rails, cannot possibly discount the usefulness of the underlying Rails libraries, or the ease with which they integrate, and Ruby of course plays a huge role in how clean Rails app code looks. The last few Rails releases have required zero changes to existing Rails apps, and the generated code for scaffolding is already pretty minimal.

AppFuse, on the other hand, is more useful to developers who want a jumpstart on stitching together the myriad Java application/persistence frameworks. Once that stitching is done however, you’re on your own and you have to learn Spring/Hibernate/Whatever (both the intricacies of their apis and configuration files, not to mention integration between them) to do your job, and you’ll have to use XDoclet generation every time you want to build. And you’ll also have to worry about incompatibilities between those myriad frameworks, and when errors strike, it’s hard to know where to start because of all the players involved: http://raibledesigns.com/page/rd?anchor=how_do_i_attach_a

They’re both useful, but you’re comparing apples to suspension bridges. I could go on, but I’d prefer my spleen to stay where it is.