Conspiracy? No, just axe grinding
Greg Luck has a problem with Ruby, or maybe it’s just Ruby on Rails, or maybe he’s just got his tin-foil hat on crooked. I’m not particularly in a mood for a point-by-point deconstruction of his rather rambling attack, but there’s a few points that I pulled out:
Ruby is slow. Yup, totally. Well known issue, and thank you Captain Obvious. It’s all a matter of how slow you can tolerate. My experience is that algorithmic choices have the order-of-magnitude impact on decisions, and that proper profiling will allow just about any language to be fast enough1 for the problem at hand. Performance has been, and almost always is, a red herring from the Complexity Crowd who are upset their temple of worship has been desecrated.
Rails isn’t smart enough when dealing with “real databases.” This is related to handling of views, stored proceedures, connection pooling. All of these are “major issues” in a big enterprise. I’ve never worked in a large integration database that didn’t use all of these extensively. Rails doesn’t support them, and while I might miss them on occasion, it’s also outside the scope of what Rails is trying to solve. I might disagree, but it’s not like DHH hasn’t made his views widely known. Not every tool solves every problem well. Rails is aimed at green field applications, not integration applications.
Rails has no caching. Demonstrably false. It might not work the way some unnamed Java stack works, but it is there, and it works reasonably well in my opinion. Again, scope is everything.
Ruby on Rails took longer than Java would have. OK, without any metrics, or background, who knows. If I took some brilliant Java developers and made them do their first app in Ruby on Rails, I would be shocked if it didn’t take 2x as long to complete. That has nothing to do with Ruby, Rails, or anything but the nature of skill-sets. Second and third projects are the point where it becomes interesting, and without metrics, well, this is just hot air.
He then goes into some bitter vitriol about who is ripping who off. If anyone’s getting ripped off, it’s Smalltalk, not Java. MVC didn’t originate with Java. Java has zero original ideas in it, but then again, neither does Ruby. This will upset people, but both are derivitive languages. That’s fine. Purity comes at a cost, as I have said before. Seriously, a littany of axes is not that interesting.
There are problems with Ruby, and with Rails. Certain aspects of the Ruby syntax grate at me, but that’s true of every language. Unfortunately, the author has conflated Ruby and Rails and allowed his personal axes about Rails’ suitability to projects that may, or may not be within its problem domain, to color his rationality. Seriously, a littany of axes is not that interesting.
As I’ve said so many times, and is so often mis-understood: it all sucks, I just want it to suck less. Doing so requires understanding context and history. Java is a great solution for a certain class of programmer with a certain class of problem. It sucks unbelievably for web applications, in my opinion. This is why a vast majority2 are written in PHP, Perl, Python, VB and Ruby. That doesn’t mean it’s useless, but it does mean that one needs to focus ones energy on more tractable problem domains where strengths and weaknesses are balanced better.
There’s plenty of problem domains for which Ruby, Python and others aren’t well suited. As always, the more tools in your belt, the better you can focus your tool on the problem at hand.
1 Something I learned in the Lisp community is that everything starts out as a list for a data structure. Some form of list, maybe a property list, but something simple. Only after the design is done is refactoring kicked in to figure out if it’s fast enough, and if not, where the speed is needed. The performance bottle neck is not where you think it is.
2 My POOMA-validated statistics say that this is 96.325%
This entry was posted at 9:32 am on 26 July 2006 and is filed under Programming. You can follow any responses to this entry through the post-specific RSS 2.0 feed.
I agree with Dave. I have been doing java for a while and it did take me noticibly less time to come up with a port of a java app at work.
Of course, it did not convince any java geeks.
Responses are currently closed, but you can trackback from your own site.
IMO your observations are right on the mark, and I appreciate the writing style, too. My only disagreement is with the statement that a Java programmer might take longer to write his first Rails app than he could have done the same in Java. With 10+ years of Java experience, I wrote my first Rails app in 1/4 the time I would have estimated the work in Java. That includes all the customization necessary to make the HTML documents conform to our corporate standards for appearance, and to plug the thing into our webapp security stuff and make service calls into our enterprise infrastructure; that is, not just an out-of-the-box Rails app. Also includes my learning curve time for niceties like ActiveRecord migrations and so forth.
Based on that experience, I would say Rails is very strong in terms of developer productivity. A great tool for tactical, customer-facing business webapps. If it doesn’t solve every enterprise problem, well, as you mentioned, that’s not its intent. It does an excellent job with the types of problems it was designed to solve.