Six Ground Rules for “Rails Sucks” Articles
This guy crossed a line, and I think it’s time we began to establish community norms about this kind of thing. I’m proposing six ground rules for “Rails Sucks” posts.
Rule One: No Ponies
You have to compare Rails to something that exists. An ontological argument based on a theoretical perfect good is not interesting, and likewise an argument that Rails sucks because it doesn’t magically integrate generated code with your hacktastic mess of a “Hello World” app isn’t interesting because programs do not magically intuit and obey your intent. The scaffolding code generation is there to start you off, not bail your ass out when you realize you have no idea what you’re doing.
Also, ActiveRecord’s ORM cannot be expected to magically work with all aspects of your database schema, including your own particular naming scheme. It offers meaningful defaults, and if you want it to conform to your own scheme, you have to configure it. (We’ve already covered why it can’t magically intuit and obey your intent.) You want something that will understand and conform to all of the foreign key constraints and database-specific tweaks you’ve come up with? Try SQL. You think everyone should be using [insert favorite database flavor here]? Get in line with the rest of the freaks.
Rule Two: Anything You Say Can And Will Be Used Against You
If you get one of the fundamentals of the field wrong, you’re out. Ruby is a programming language and Rails is a web framework; this is not paint by numbers. So, for example, if you say that the “relation” in “relational database” is how tables “relate” to each other, sit down, shut up, and start paying attention in class. If you can’t be bothered to learn about the relational model, I’m not willing to listen to your opinion on anything based on it, including database-driven web development.
Please make sure that the easiest explanation for your criticism is not your own lack of knowledge.
Rule Three: You Not Getting It != Rails Sucks
Any complaints must be real, in the sense that they have at least a foothold in consensus reality. You have to restart WEBrick to load changes to the database schema in development mode? No, no you don’t. You have to restart the web server when you:
- Edit anything in the
config,lib, orvendordirectories.
That’s it, and it’s a damn waste of a ol element. That’s consensus reality right there, and if your experiences don’t match up with it I can only assume that you’re either trying to use Apache+FCGI as a development platform (in which case I punch you in the neck) or you’re totally delusional (which is actually preferable to using Apache+FCGI as a development platform, and not because of me punching you in the neck).
If you try to do something stupid, you will be frustrated with the result. This has nothing to do with Rails; it’s how life teaches you to be less stupid.
Rule Four: Programming != Zen Koan
First there is a scaffold. Then there is no scaffold. Then there is.
A newb asked DHH, “Does ActiveRecord’s ORM have DRY-nature?” “Nej,” replied DHH. At this word, the newb was enlightened.
Learning is something which takes effort, and if you’re expecting anything complicated to not require effort, see Rule One. Yes, the documentation needs to be improved.
But this is just too-much-cough-syrup crazy talk, plain and simple:
What gets me is I am just *not* going to pay to read 570 PAGES about a framework! I’d actually pay twice as much if they could boil this sucker down to 200 pages or less!
This is an actual quote. If you actually expect to be able to learn how to effectively use a full-stack web development framework based on man pages, blog articles, and the kindness of strangers, and if your objection to getting a book is that it’s too long… actually, you know what? This right here explains the entirety of his rant. There is a manual, but it takes longer than the average bowel movement to make it through the damn thing. Well there’s your problem right there: you don’t want a web development framework, you want a copy of People. “Ooo! Brangelina photos!”
(God only knows what this guy would think of Knuth… “Three whole volumes?! But I wanna know C now!”)
Rule Five: No Doomsday Scenarios
Rails sucks because it wouldn’t be able to handle my trillion-table database which spanned galaxies in its conception and is normalized to the 17th form–down to the letters. Until Rails is ready for the enterprise, it’s just a toy.
No, nothing will solve your imaginary (or, *shudder* real) enterprise situation, Rails or otherwise. If you’re honest about it being real and having a bazillion tables, etc., etc., I suggest you start saving snippets for The Daily WTF and looking for a new job. No web framework, no matter how it’s described to you by a Web2.0 blog, will ever fix the horrendous mess that is that schema, and faulting Rails for not being able to undo the atrocity performed by either you, the DB admin, or some hobo they kidnapped off the streets is a psychological coping mechanism, not a valid critique.
You’re looking for a glass of whisky the size of your chest, not a web framework.
(Unless, of course, you’re just making things up for the sake of argument. But really, who does things like that?)
Rule Six: “Rails Sucks” Is Not A Good Way To Ask For Help
There are plenty of people willing to explain how things work, and the Rails community is growing by leaps and bounds. If you were to ask them, say, “why do I have to always restart the web server to see my changes,” you’d get help. If you post a “Rails sucks” article on the JoS forum, you’re going to get made fun of.
Conclusion
I’ll arm-wrestle anyone who says DHH isn’t Apollo incarnate.
17 comments »