The Case Against Ruby on Rails

Some blockhead wrote this absurd critique of RoR. Thought some of you
might want to comment on his article. Just search that page for "max
hodges" to see the reply I posted:

whiterabbit wrote:

Some blockhead wrote this absurd critique of RoR.

A Joel Spolsky wannabe?

Try "RoR has no concept of relational data tables" (IIRC).

There just aren't the words for such stupidity!

whiterabbit wrote:

Some blockhead wrote this absurd critique of RoR. Thought some of you
might want to comment on his article. Just search that page for "max
hodges" to see the reply I posted:

Tip: A great way to drive up hits to your blog is use it to flame some popular industry trend. A certain blogger by the initials JS does this, sometimes.

And note that my statement here is an "argument to money" (/argumentum ad crumenum/). The argument that a statement is true or false because its author does or does not have a financial motivation. Keep your eye on this fallacy!

There appears to be considerably more demand for Rails programming than there are Rails programmers

When you are spinning, lead off with obviously true and complementing statements that lead your audience along with you.

the trendiness ... of Rails has inspired a legion of business visionaries to increase their demand

And then hit then them with the /argumentum ad crumenum/. Yes, we are inside a bubble, and yes many people are out there with the get-rich-quick schemes.

If this weren't Rails's own fault, then the author's own admission must be placing Rails ahead of the pack. If it's ahead of the general LAMP projects, then it must be ahead of the bubble and the get-rich-quick schemes too, right?

Yes, [they're] the great pretenders ...The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand.

This statement is a thing of beauty. When you say that "mediocre programmers can use Brand X to pass themselves off as proficient", you are actually giving Brand X a very high complement. The point of a framework is make hard things easy, and bring the harder things within reach.

The Visual Basic effect . A corollary to the fact that "pretenders" are besieging the market is that Ruby on Rails provides so much scaffolding, hand-holding, and out-of-the-box functionality for developers that inexperienced/unsophisticated developers are able to initially delight clients with early releases.

Now refresh my memory here - I have only repressed about 5 years of VB work. That idiotic language had a _horrid_ plugin system (which OCX protocol would you like to scramble your registry today?), and I don't seem to recall it supporting unit tests. Of all the alleged languages out there, the only one that _resisted_ unit tests harder than VB is Lotus Notes!

Rails, as people who have actually used it know, doesn't turn anything on out-of-the box. What Ruby's incredibly expressive dynamism gives us is a very wide set of options, and a very short amount of programmer time accessing those options. VB did not support '3.seconds.ago', for example.

That's not syntactic sugar. Scarce, minimal, and expressive statements provide scalability - an area where VB did not exactly shine.

But maybe the author would like to decry a super-low line count as a sign that something is wrong...

No Swiss Army Knife ... Ruby on Rails was developed to do one thing and one thing well: help teams write web applications with user interfaces that perform basic operations on relational databases.

But - I thought you just said that Rails had lots of plugins and out-of-the-box functionality!

Period. If you have complex processing needs such as message queuing, quantitative optimization, etc you'll need to either (a) look somewhere else

Correct. And you can throw in Rio or BackgrounDRb or zillions of other Ruby gems, all instantly compatible and written in < 500 lines.

(b) write it into the framework (not likely as the shepherds of the framework are zealots and opinionated about protecting it from "unintended uses")

The spectacular stupidity of this statement makes me think it's just bait. Of _course_ the maintainers won't accept every patch you write. The author must actually be unaware that Ruby allows anyone to re-implement any method they like, and monkey-patch any fix. Rails's internal architecture is written under the constant constraint that it's always open for extension. How many markup languages are we up to by now?. Hence, the maintainers protect their kernel from excessive patching _expressly_to_preserve_ this extensibility.

or (c) find a way to integrate with other technologies which support your business requirements.

Oh, the horrors. Maybe I can link to C++, or pipe to an external program, or reach into the server for a module, or send commands thru the database, or ... oh wake me up when the list is over, okay?

And note that each of this blockhead's "or" details are really an "and". You can mix-and-match any set of those kinds of solutions.

Still no mention of unit tests, or how far behind Rails all the other Web frameworks lag there...

No Throat to Choke and a Chasm to Cross ... If what you want is an alpha, beta, or a version one application that you may re-write down the road, Rails may be right for you, but if you've got shareholders you must answer, teams you must attract, grow, & maintain, or business groups you must support with vendor options and a cadre of capable employees, Rails is an iffy choice.

Excuse me, Steve Ballmer. I am aware that if my Open Source Software breaks I can't sue anyone, but are you actually implying that if my Microsoft software breaks I can actually sue /Microsoft/?? Yeah, and I got a bridge to sell you, too...

Meanwhile, my day-gig has delighted shareholders who will not let us go back to Brand X, a healthy and _minimal_ team, several internal and external business groups to support, and zero bugs. Not a low bug rate, not "just display bugs", not "we will fix the easy bugs later after these hard bugs". We have no bug tracking database, and we run for months with no bugs reported from the field.

There are no/very few established vendors backing Rails

Just books from every technical book publisher...

Maaaybe the tools that come with excessive certification, classes, and marketing are the tools which NEED all that crap because they SUCK, huh?

In conclusion, this guy's arrant clumsiness wouldn't even qualify him for a job on Fox News as an expert speculator. He has only come up with the shallowest and most easily-debunked spin.

Those are just idiots posting to get dugg and make some bucks from
adsense or whatever. Why even read.

I actually agree with many of the points he makes, but so what? I
mean, it's like saying that Java isn't the perfect programming
language because it won't cook me dinner. You have a task to get
done and you're going to have to make a choice as to the best tool
for the job. For some tasks it's Rails, for others it's Java. For
others still it's Visual Basic. All the data points in the world,
for or against, are kind of useless without a context in which to
evaluate the decision.


Perry Smith wrote:

Tip: A great way to drive up hits to your blog is use it to flame some
popular industry trend.

So, my not just ignore him completely? Don't post a link to his article or anything. Just ignore.

"There is no honor in preying on the weak." --Lt Worf