But Justin, didn't you just write a book on and promoting Spring, also covering Hibernate? Of course you did, I contributed a chapter to it. Given that, I guess I would've expected you, if anyone, to understand the approaches and techniques Spring employs to reduce lines of code vis-a-vis direct use of EJB, or even an ad-hoc POJO-based solution for that matter. It's clear WE need more hard numbers demonstrating results there, but it's a shame that story wasn't told here... In any case, you could certainly scale your app up to an EJB solution, building directly on the EXISTING POJO-based architecture you've already implemented. No rewrites man, that's the beauty of Spring. In that case, Spring will eliminate boilerplate EJB-client access code, as well as boilerplate EJB implementation code (though introducing the thin EJB facade layer and the additional deployment descriptors will certainly still add to LoC.) *sigh*

I'm not sure what the *sigh* is about. What I'm saying is, I understand perfectly well that the Spring/Hibernate direction saves me code over, say, a traditional EJB app, but loses me code over, say, a C app, but I can't just say "well, the EJB version would have been another 3,452 lines of code" because I don't know for sure what the numbers would be, and don't have the inclination to go write it and find out. My overall point was that Mike Spille was complainig about LOC counts, but not asking the full question. I apologize if that wasn't clear in this post. So, to re-iterate again, if somebody wants to organize an open source Ruby-off, I'm all for it, and I'll contribute. I'm sorry I can't open source what I did on this project, but I'm sure everybody out there still remembers there are these things called paying customers who get to make the decisions. :-)

Ahhh, l see it. I should have said "I can't answer the question *exactly*". Sorry!

Justin, let me exagerrate grossly for a moment to demonstrate the gist of my point. A literal "Hello, World" app is trivial (e.g. one that prints "Hello, world" and exits), and any attempt to make statements about the environment in which you write "Hello, world" are meaningless. That's my point, exagerrated. There are a class of applications trivial enough that you can't learn any real lessons from them. People can (and will!) argue where the cut-off point is for "trivial" and where you start doing something intesting enough that you really can draw conclusions from it. But I really, really don't think 3K lines of Java, or 1K lines of Ruby, is it. I'm really sorry, but I don't think you can spend 4 days writing a thousand lines of Ruby on Rails stuff and are now qualified to say RoR is a viable competing platform to Java. Sure, if you want to say "RoR is a viable platform for apps that can be written in 4 days", knock yourself out :-) This is really where my exagerration comes into play. To someone who's written 1K lines of Ruby, the Hello, World app is trivial and you'd probably mock anyone who tried to draw conclusions from it. Well guess what? If you're used to working on apps that start around 50K lines of code and trend sharply upwards from there, then talk about a 3K or 1K app are going to seem silly. You can very, very legimately say that there are a number of reasons why you might pick Java for that 50K line app - reasons which do not apply to the app written in less than a week. You've kinda/sorta "proven" that RoR works for a single guy working alone for a week. You don't seem to realize that _that's all that's been shown_. Look at this from other people's perspective. Some guy out there says "I spent 6 months part time on a Ruby app - then in 4 days I rewrote in the new Foozle system!". Tell me Justin - what conclusions will you make about this application? Forget about what "Foozle" is - what do you think of the app that's rewritten in 4 days in Foozle? Is Foozle some unbelievably powerful language system - or was the app just kinda small and lame? Where would you put your money - that Foozle is the next big thing, or there probably wasn't much to the app to begin with, and whether it's Foozle, C, Perl, PHP, RoR, or Java doesn't matter all that much in the end.?

My issue here is the public has no way of judging the merits of this comparison, and I highly suspect there are fundmental architectural differences between the two versions that account for at least a decent portion of the LoC differences. In other words, you're not entirely comparing language vs. language here, you're muddying it by comparing development frameworks and architecture. You're also not attempting to explain *where* the Ruby version saves and the Java version bloats, and why. I wouldn't doubt it if the Java version was overengineered to begin with. But it's all speculation at this point. What I read is hype in support of your next book. That's what the sigh is about. Promote all you want, certainly, you're doing a great job. I'd just like to see a little community contribution, too, while you're at it.

First of all, Mike, you are using a figure from an old post to exaggerate. My original post said I'd spent four days rewriting the app. I've now been working in it for two months. Two months still ain't 2 years, but its a heck of a lot more than 4 days. Secondly, if you failed to note the history here, I'll reiterate it: I posted a nice little "hey, I had a good experience with Rails" blog entry. I was then called out on the matt for being a charlatan because I didn't produce numbers. I have since produced numbers. I am sorry that the app I am working on is so trivial, but its the only numbers I have. I further extrapolate, based on a) my two months of working in this platform, b) my 15 years as a programmer, and c) some common sense, that I think that this Rails thing could really work. I haven't said anywhere that Java shops (or .NET shops for that matter) should run screaming from their dev environments, nor that Ruby and Rails will replace Java. I have said that I see a lot of benefits to this environment, and its a really productive place to be. Look at this from my perspective: all you have done here is say that my work is trivial and, here's the important part, that I'm not smart enough to extrapolote whether or not I think this technology is useful from my sample. I *have* to extrapolate, or I'd never try it on the next, bigger project. Let me put it another way: there is nothing in the Ruby language, or the Rails framework, that would impede me from trying it on the bigger projects, and I happen to believe it would work. See my post about additions to the framework above to see where I see the limits. Finally, here's the original conclusion I draw in the original post: "I think that there is a lot to be said for Rails, and it deserves much of the press it is getting. However, I don't think its a Java-killer. I think there are plenty of applications, and development teams, that are better suited to Java and its immense universe of available support libraries. I certainly am not going to stop developing in and learning about Java just because I've discovered Rails. On the other hand, I am going to spend more of my time trying to find projects that I can use Rails on." I frankly don't find what's so offensive. I suppose I could have ended the post: "And here's what I learned: Java sucks, and Rails is the answer to every question." Which seems to be what you think I said, but it isn't. So, I'll go out on a limb one last time and say: my experience with Rails so far has been pleasurable, and surprisingly efficient, and based on that, I'm willing to try it out on bigger, longer, uncut projects because I haven't found anything yet that would stop me.

Keith -- see new blog entry.

Wha? :-) You mean the "What is missing" entry? I'm not as interested in what Ruby may be missing, as I am as interested in seeing code side-by-side proofing what you and Bruce have been claiming. Partly because we want to learn, partly because we want to critique (let us show you how many of those lines can still be shaved given we know its not a complex app .... ). That's the community contribution I'm talking about! Don't tell me I have to buy the book first!? :-)

Ah I see now, nice :-)

When comparing the flexible Spring/Hibernate setup and architecture with the integrated end-to-end solution of Rails, you're comparing two entirely different styles of application development ... and above all you're doing it on a small application where the overhead really makes a difference. RIFE, the framework I work on, was initially targeted at small to medium apps and after Ta-da List's announcement of the low line count and me calling it a stupid app, people basically told me to shut up or put up (http://rifers.org/blogs/gbevin/2005/1/22/re_hype_ruby_on_rails), which is what I did (http://rifers.org/blogs/gbevin/2005/3/18/blabla_tada_in_java). Sorry if this is all already known to you, then just disregard this comment ;-) In this experiment I took the quick win approach in coding exactly what I needed, where I needed in RIFE. Along the way I added a couple of features that I found were missing in Ta-da and fixed some problems. Even with a language as Java that is essentially already more verbose than Ruby (and I did count the lines with }), I ended up with only 50% more (300 lines) and imho a nicer setup. So in that experience the size of code isn't that much more. It's thus quite dangerous to say something about 'Java' versus 'RoR'.

Geert, Exactly what we've been saying as well--a large majority of Justin's results come down to architectural choices, and fundamental differences in those choices in the Java app vs. the Ruby app. Just one thing: Spring is a bit different in Hibernate here, as, like Rife, it's a "use what you need" application framework. While, Hibernate enforces a flexible Data Mapper approach to ORM, Spring doesn't mandate use of Hibernate. In other words, you can take a similiar quick win approach Spring, using exactly what you need, where you need it. "It's all about choice" (that's our tagline, but I admit I really like yours, too, "use what you need") :-) Cheers, Keith

Very nice write up...

But I'm not sure why.

I'm working...

Gonna have to give it a try.

Thanks for the write-up.