A ‘When Rails Fails’ Follow-up

About 18 hours ago I posted When Rails Fails, in which I showed what happens if you make simple mistakes in your Ruby on Rails code. The response was pretty massive. 30 comments were left on the post itself, and more discussion takes place on reddit and hacker news, plus I received some messages on twitter. Most memorable is this one.

Criticism of the article falls into a number of categories.

Category #1: Denial

You are talking crap, those error messages are pretty good!

It saddens me that these error messages are perceived as "pretty good". It tells you something about the state of tools today. If we go back to more basic programming, for instance in Java. You write code which contains errors. You compile the code, the compiler tells you "this objects has no such method at …". "That class does not exist at…", "variable not declared at …" You may hate Java and everything it stands for, but admit it, having this type of error messages is pretty convenient, isn’t it? Wouldn’t you prefer clear to-the-point domain-specific error messages over a stack trace with an obscure error message? If you say that the error message makes perfect sense, that’s only because you’ve encountered it before and remember how to resolve it, not that the error message is in fact clear.

When I mistype the name of a controller in routes.rb and the error I get is "uninitialized constant HommeController", that is a bad error message. Better would be "At line … you refer to controller ‘homme’, but no such controller exists." Are you honestly going to argue with that? You may say, "sure that would be great, but this is enough for me, I can handle these types of error messages." And sure, you may find these errors acceptable and trade off well with the advantages of Rails as a whole, but do not tell me these error messages are perfectly fine.

Category #2: You think this is bad, try a Java framework!

Tell me about it. I have no intention of singling out Ruby on Rails here. I’m in no way a Rails hater. Rails was simply my first example to uncover there is a problem here. Later today I’ll publish a similar post about the Java Seam framework. Update: Here it is: When JBoss Seam Fails.

Category #3: You are simply a bad programmer!

I can’t help but immediately judge the author to be one of those NNPP’s who spends days tripping over ridiculously simple issues because they never really grokked how to debug in the general sense. I’m not claiming the author is an NNPP, I’m just saying when you get hung up on the basics like this that’s the impression that is conveyed.

Another:

I hate rails for several reasons but either you just started programming, or you are trolling.

I like these, especially since I clearly pointed out:

To test this out, I followed Rails’ "Getting Started" guide and made "accidental" mistakes along the way, to see how the system would react.

I made these mistakes "accidentally" (note the quotes). Quotes imply sarcasm here. And I’m not even going to defend my programming abilities.

Category #4: Poor attention to detail is going to bite you in the ass as a programmer no matter what technology you’re using

True, but it is the tool’s job to help you as much as possible when you do screw up, which you inevitably will. Rails (as shown) does a fairly bad job at that. However, not everybody seems to agree, from the comments:

Wrong. It’s not the framework’s job to do anything. Rails isn’t for lazy people.

It’s not the framework’s job to do anything? Are you serious? Why do you use it? Isn’t the point of Rails to do less work, to make web development fun, to make work more productive? Isn’t making mistakes part of that?

Category #5: Where are your tests?

Would my error messages be less obscure if I uncovered them by writing unit tests? At most it would make localizing errors easier.

Category #6: If you don’t like it, go use Java! Screw you!

Very mature. When I post my article about Java Seam today I expect far less response, or at least far less radical responses like these. People tend to get religious about their programming language. Today Ruby on Rails is their God, so whomever says a bad thing about it, shall be damned. And screw you too, for that matter.

Category #7: Let me help you

There were a number of people that offered me help, teaching me how to debug these issues even offering to contact me and help me out. I appreciate that a lot. It’s sweet. And it’s great that there are such friendly Rails people. I am not a struggling Rails developer however. I am interested in Rails, because we’re developing WebDSL, a Rails competitor. I’m looking at various web frameworks and observed that simple programming mistakes are often fairly difficult to track down. In WebDSL we attempt to solve this problem. I appreciate the intent, though.

Tags: ,

This entry was posted on Thursday, November 12th, 2009 at 10:17 by Zef You can follow any comments to this entry through the RSS 2.0 feed.

  • Thomas
    No matter what some folks say, I did like your article. You could do one about Django, if you feel like it. I've had some pretty confusing messages there too, and I wonder how it compares to Rails.
  • Xiong Chiamiov
    Alex Gaynor started on that: http://lazypython.blogspot.com/2009/11/when-dja...

    Unfortunately, he didn't get very far.
  • People, I think, you still don't get him:)
    Zef is just showing one of the weak points of internal DSLs, which is no support for true domain specific model/program validation.
    In this way, he wants to promote approach of the WebDSL, which is an external DSL, which can easily support such validation I guess.
    MDSD and DSLs for future folks!:)
  • All religious responses set aside, and maybe slightly off topic, but I find this topic typical of a low quality standard in IT. Now before you go trash me for that statement hear me out. ;-)

    The issues you are debating here clearly do not make Ruby a bad language, or "suck". It's clear that is not what you are saying, though some people appear to think so. I believe that though one might say the error messages as they are now are sufficient, as ultimatly you will most likely find the problem, this is an area where great improvement is possible. To say that even though improvement is possible and would be virtually without downside, and helpful for both beginners and experts it should not be changed, baffles me.

    I can only explain this with a low quality standard, as apparently people consider what we have good enough and any improvement unnecessary. In my opinion this is ridiculous, as I said, better error messages would be an improvement for everyone. I would love for way more people to set the bar higher and improve upon stuff like this. I'm convinced it would result in much better software in general, and an improved experience in using software. I don't see any downside in that.
  • Xiong Chiamiov
    It's not Ruby that has a problem with error messages, it's Rails. The messages are mostly just default messages from Ruby, which would be helpful if you were writing your application directly in Ruby, rather than have code generated by a framework.
  • a smart dude said once that "if you live in a house made out of glass, you shouldn't be throwing rocks at other people's houses" - this is exactly the case here, a self-righteous, picky and on top of all misleading post like is exactly what you shouldn't be doing when you own "special" framework sucks ass. @zef should first concentrate his efforts on fixing his own crap before trying to point out stupid and redundant examples for pseudo errors.
    My @zef need a bit more assistance when trying to tackle bugs and errors in his own code, but I think that Rails's errors (e.g "Routing Error" in this case) is far more self-explanatory than webDSL complier errors.
    This is merely a stupid publicity stunt made only for this cause of pulling some traffic to webDSL, too bad it sucks so bad that I can't believe anyone from the web development industry is going to even try it, never the less go production with it.
  • Xiong Chiamiov
    Saying that people need to present a solution before bringing to attention a problem is just silly.
  • they only need to do so if the ARE WRITING A FRAMEWORK THEMSELVES. blaming others while your very own code does not stand up to your demands is not only silly, but rather hypocrite.
  • Michael
    It doesn't sound like your listening...

    Let me repeat the wise words from Xiong Chiamiov:
    "Saying that people need to present a solution before bringing to attention a problem is just silly."
  • some guy
    Most of your criticisms were valid, in fact I hope the community takes what you are saying and fixes it (in so far as that can be done). My one gripe: you singled out a case where you mistyped confirm and therefore you deleted objects without warning... this is exactly where TESTING would save you. And implicit in the Rails concept is TDD/BDD .... using Rails without tests is not just bad practice, it's really really hard (some of your errors show why).

    What that means: the Getting Started Guides should talk about how testing is integral in the Rails development process.

    Thanks for the analysis, by the way, for every person who got angry there was at least one who nodded to themselves.
  • lionsburg
    Yes, testing could have saved him. However, it is inconsistent behavior from the rest of the framework by not issuing a warning.

    For example, ActiveRecord when presented with this:
    User.find(:all, :some_unknown_arg => 1)

    Will throw this exception:

    ArgumentError: Unknown key(s): some_unknown_arg

    Why is it not reasonable to expect link_to to behave in similar fashion?
  • Yap, you made it. you actually succeeded in posting something a *little* more idiotic than your first post. i under estimated you, i admit.
  • Gosh, I love the internets. The things people will say to you when you cannot punch them in the face.
  • Yeah...Just proves my point. You are welcome to try, at least you won't be writing crap for a couple of days trying to find me.
    But srsly, i'm impressed. that is the most beautifully crafted double-fail i had ever seen.
  • BTW, i guess i am the only one that bothered to check how well that crappy webDSL reflect errors.

    one word for it:

    *sigh*
  • Xiong Chiamiov
    He said was that he was examining these other frameworks so that he could improve WebDSL in that area, implying that he is perfectly aware that it needs work.
  • i will believe such integrity exists when i'll see a "a webDSL fails" post, but i won't see one like that. this stupidity has gone far worst than it was ever intended to on my behalf, and i really hope to get to meet Zef one day and show him my appreciation to his professionalism face to face.
  • Alright, play time's over. Either behave or go annoy somebody else.
  • what's wrong nancy? did i hurt your feelings?
    you are the most hypocrite person i had the chance to read through his stuff, you never seize to amaze me.
  • lionsburg
    What you are commenting on is completely reasonable and there's no reasons why the framework couldn't have that checking it in.

    Another response to your Category #5 "Where are your tests?" is: Tests doesn't automagically point to where a problem is. It may get you close. Most of the examples you provide the framework could pretty easily issue warnings to help you zero directly in on the typos.

    Good luck with the crazies and religious zealots.
  • One issue remains: while a dedicated DSL, such as WebDSL, may be able to solve a lot of the "problems" the author identifies in Rails, it find it hard to believe that WebDSL is just as extensible as Rails. I mean, in a dynamic language I can easily extend the DSL for my own purposes, e.g. by adding a new form helper. I wonder how easy that would be in WebDSL -- and I don't mean that in a sarcastic or rhetorical way, I really do wonder.

    Are we going to see some kind of trade off here: flexibility (internal DSL based on a dynamic language) vs. ease of use (external DSL such as WebDSL). Could you comment on that Zef?
  • You can extend WebDSL as well, but for many things you'd have to extend the compiler which requires (in our case) knowledge of Stratego/XT. So indeed, there's a trade-off there.

    Some things you can do in WebDSL itself, however, you can of course define your own functions and templates. We're also doing a little work on a native class interface, so it's easier to call Java code from WebDSL.
  • T, Rails Programmer
    I agree with the author, that Rails error messages are bad. Usually an error message is just a huge stack trace, with some strange error message at the top. And the place the error originated from isn't even at the top - it's somewhere in the middle of the stack. Now of course I've learned how to read these error messages but at first I was absolutely baffled by them. Some of these errors would be really easy to detect. Like some method expects an integer instead of a string or something (just an example!). The method passes the (wrong) argument to some internal rails methods and it blows up there. Instead there could at least be some sanity checks which spot the error at the place where it happens.
    There should be a guide on how to debug Rails errors, among all the other guides which boast how easy and fun development with Rails is. It should be part of the official documentation. Because when a new user read the tutorial and makes a tiny typo error then he is totally screwed and the "fun" of rails is lost for him.
  • Onno
    So what's stopping you from writing that debug guide right now?
blog comments powered by Disqus