The internet definitely gives a platform for people who don't know what they are talking about to make their opinion known. Unfortunately systems that rely exlusively on popularity (ahem digg, reddit) tend to give these people their limelight simply because they make such loud statements.
In particular I'm referring to this rant
on the Joel On Software forums. Overhyping a product is just as bad as slandering it with false information, so I'm going to respond to this rant point by point, but I will apologize for my strident tone. I have to admit, I'm not really known for suffering fools gladly, and this guy really rubbed me the wrong way.
A little note before I get started. I have been a professional database developer since 1993, and I have worked with numerous enterprise level database systems and frameworks. I have worked with Rails for about 15 months and I'm now working on my fourth major project in Rails. You can view my commentary with that perspective.
"1. IT TAKES THE RELATIONAL OUT OF RELATIONAL DATABASE MANAGEMENT SYSTEM"
In this section the poster talks about how Rails isn't relational, and it just doesn't grok relational databases. His major point seems to be that Rails should be smart enough to look at your tables and infer the relationships based on the primary keys. First of all it's not clear when he thinks Rails should do this, is that when he's generating his models, or at runtime? Let's just assume he's not stupidly asking for a runtime performance graveyard like that, and he just wants it to happen when he's scaffolding out his models (see sidenote on scaffolding).
The problem with that type of introspection is easy to see on simple inspection. First, what if all of the tables you are joining to with your model don't exist? Should it re-inspect every table in the database every time you create a model? What happens if your naming convention isn't exactly how rails expects it (ie, some_descriptive_tag_table_name_id), the current system easily and expressively handles that situation. What if you have some special select logic that you need to do on your finds? Again the current relationship handles it very nicely. The current system has all the power and expressiveness you need to capture very complex relationships. It seems like he's really arguing that Rails should "just figure it out", which to me is a dubious claim to begin with.
The ranter then mentions something about not being able to leave the table, and Rails has taken a latex glove to his database schema. To be honest this entire section was very confusing and poorly worded, but he did make some relatively clear statements that were of course totally off base.
"There's still no excuse. Because Rails insists I name my foreign key columns table_id if I want to live the good life. When I do so, I shouldn't have to declar has_many and belongs_to."
Um...What? How about this:
belongs_to :user, :foreign_key => "user"
If you want to live the good life? What's that about? Is someone going to throw you in the river if you don't comply? Let me tell you something. Rails is very tolerant, and very nicely handles situations where people don't follow the standard. Personally I can't stand pluralized table names or using id as the primary key for my tables. So to live the good life do I have to do that? Hell no, I put these two settings in my environment.rb:
ActiveRecord::Base.primary_key_prefix_type = :table_name_with_underscore
ActiveRecord::Base.pluralize_table_names = false
at this point I now have the bliss of tablename_id as my primary keys, and I don't have to mess with any of the pluralized table nonsense. My model is named exactly the same as my table, so if I want an ORDER table I make an Order model, or if I do want to pluralize I name my table ORDERS and my model Orders. The point for me is that I don't have to worry about the pluralizer getting it right. In the context of this article, the point is that Rails supports this choice all the way throughout the system. Everywhere that it matters, the system just knows that I've made this choice and everything still works as if I were a normal Rails citizen. Pretty cool huh?
Ok, next the ranter goes off and starts talking about popups. To be honest, I have no clue what he was talking about here. I don't get too many popups at the command line, so I'm at a complete loss as to how to respond here. I'm going to chalk those comments up to either drugs, or complete cluelessness on his part.
So basically this entire point was complete and utter nonsense. This guy wants something that will go and do the work of figuring out what his foreign keys are for him. How does that translate to a restriction of Rails? Seriously, this guy should learn how to use the relationships in rails before he starts ranting about how bad they suck.
Ok I have to admit that I hate scaffolding. It was one of those things that got people interested in Rails, but in my world I never use scaffolding. Occasionally, when I just need a bunch of skeleton files I'll scaffold them out, but scaffolding is no more Rails programming than unlocking a car door is the essence of driving. Real true Ruby on Rails programming has almost nothing to do with scaffolding.
***End Scaffodling Sidenote***
"2. RAILS DOESN'T PLAY WELL. WITH ANYONE. NOT EVEN ITSELF."
"But do you remember that moment in the demo when the play turns ugly with a big ole error page? It's when he tried to update his db schema or model or something. It doesn't work because he has to reboot the webserver before those changes take effect. Which he says and moves on quickly."
Seriously, wtf? Did this dude actually write some code in Rails or did he watch the demo and assume that's how the system works? I've been working on the same system now since october and I've had to restart my web server less than 10 times. In fact the only time I've had to restart was when I changed the structure of things I had stored in session variables and I wanted to purge them. I probably didn't even have to restart the server then, but I figured I'd do it for good measure. When it comes to typical active development though, if you are running in development mode, you just don't have to restart that thing....*ever*. I add and remove tables, change the structure, add and remove models, change the assocations, etc, etc. I never have to restart the server in those cases, with the one exception noted above. Seriously this item makes me very seriously doubt the veracity of his claim that he has actually built an application in Rails.
Next he talks about how if you re-scaffold something it will overwrite your files. Which is true, *if*, when you hit the part that says "overwrite files (y/n/a)?" you hit a, or y repeatedly. Now look, Rails does make database programming easier, but it does help if you can use a computer and you understand basic prompts like "hey, you have some crap here, do you want me to overwrite it?".
Once again we have a complete rant section that isn't based on the Restrictions of Rails, but on the ranters own incompetence.
"3. YOU CAN'T READ THE FACKING MANUAL BECAUSE THERE IS NO FACKING MANUAL."
Wow, seriously this is such a load of crap. There are several good manuals written for Rails. Which you can buy from Amazon. The one written by the Pragmatic Programmers is $23 for a 450 page book. Apparently the fact that the book is over 200 pages is a huge problem for this dude, my advice, read the first 200 pages. In that time you'll have read enough information to be significantly farther along than you are now.
He also bashes on the api.rubyonrails.com, which to me is one of the best aspects of the Rails documentation. I don't know of any other language that has such complete documentation online.
Certainly documentation is difficult. It's often times hard to know where to start, or where to look, but everytime I've picked up a language, I head to the bookstore and buy a book that covers the topic I need to learn. If you are completely against buying books, well the problem isn't with the language, it's with your self imposed restrictions.
"4. RAILS ATE MY DATA, OR AT LEAST STOOD IDLY BY WHILE MY DATA WAS EATEN"
Again with the WTF? How is this even a rant about Rails? This guy is just boldly stating that he has no damn clue how to build software. Seriously, Rails has this whole wonderful thing called validations. If you want it to validate your data, you have to tell it to validate the data. Programming languages and frameworks don't write the software for you, they just expose features and functionality that allow you to easily write code. He then complains because Rails knows the database is only 40 characters and it should have checked the data first. The problem here is that most real database systems won't silently fail, so it's a massive waste of CPU to do a check that is completely useless in most cases. That's why you have to explicitly tell Rails to do the check, because it tries not to uselessly waste CPU cycles. Next.
"5. THE FIRST RULE OF RAILS IS: DO NOT TALK ABOUT RAILS' RULES!"
Every significant framework has rules, and lots of them. He complains that none of these rules are out there for people to read. As I said before, if he read the first 200 pages (since that is his limit) all of those rules would have been covered in great detail. If you fail to do even the most basic research, he is right, those rules would be frustrating and irritating if you just kept tripping over them. Again though, the stinging indictment is that he is lazy, not that the information isn't there, and there in abundance.
"6. THERE'S MORE THAN ONE PLACE TO SAY IT"
He is apparentely talking about Engines here. The last time I looked Engines were an add on to Rails, and they weren't part of the core system. Regardless of that, Engines are a way to allow you to build components to re-use across projects. Building systems that you expect to reuse does require a bit more effort than writing that code once, however again that isn't really a restriction of Rails, it's an arbitrary requirement of an add-on libary to Rails.
This entire rant was misguided, and I didn't feel like he made any actual good points. I am certainly not claiming that Rails is perfect, but if you want to fix something it definitely helps if you learn what you are talking about before you write up some long winded post exposing what an idiot you are.