Loading ...
Sorry, an error occurred while loading the content.

The Case Against Ruby on Rails

Expand Messages
  • Phlip
    ... 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.
    Message 1 of 1 , Jul 6, 2007
    • 0 Attachment
      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:
      >
      > http://alterlabs.com/general/articles/blasphemy-the-case-against-ruby-on-rails/

      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.

      --
      Phlip
      http://www.oreilly.com/catalog/9780596510657/
      "Test Driven Ajax (on Rails)"
      assert_xpath, assert_javascript, & assert_ajax
    Your message has been successfully submitted and would be delivered to recipients shortly.