Rails is 100% magic with 0% design
groups.google.com
groups.google.com
-AR find works fine for me, in most cases, in those cases you can always fall back directly to SQL (has happened a total of two times for me). The guy very incorrectly states that the :group stuff will choke in Postgres. It does not. There is a separate driver for each database that will make the queries compliant with the specific DB.
-When using joins, you're supposed to use :include, or has_and_belongs_to_many. These are NOT read only, and work very very well. He's complaining that something he is doing the wrong way does not work. That is because he is doing it wrong, and it isn't SUPPOSED to work.
-I agree with his point about understanding Rails and the options hashes. At this point, I really wish that Ruby had named arguments, as the options workaround gets really annoying.
-I don't understand what he means by quality assurance. Rails has an incredibly large automated testing suite. I've been using Rails for two years and I've found one bug. I really just have no idea what he's trying to get at.
-On the last point, about the "big-picture", he is provably false. If you've written a Rails app and there is even ONE XSS injection opportunity, you've done it wrong. Spend two seconds in the API docs and you will find this function called "sanitize":: http://api.rubyonrails.org/classes/ActionView/Helpers/Saniti...
It helps if you read the fucking documentation before you criticize something.
the complaint he makes about the options hashes would be solved if someone took the time to document all of the private methods, etc. I like a mix of code + documentations to figure out how something works. Most of the rails contributers prefer to just read the code, which is why no docs exist.
"- Reading and, in general, understanding Rails is horribly difficult, since it's no design and layers upon layers of magic. Very often you will find 5-7 layers of functions delegating the work deeper and deeper in, until you arrive to a completely undocumented internal function that in turn splits the work to three other, unrelated internal functions. Given that each of those 10 functions takes a hash called "options", each layer altering it subtly, but none having the complete picture, and that 9 times out of 10 that hash is not documented on any level, figuring out what your choices are is pure hell. It's made even more fun by the fact that different parts of Rails are accessible at various points of handling the request, and you can't just jump in and poke things from the console, since it won't have 99% of the things that only magically spring to life once a request is live. "
Methods do really nest pretty deeply sometimes. And since all of ruby's classes are open, people just add stuff by hacking things together. It's pretty much impossible sometimes knowing where a particular method is in the codebase.
This is probably the case here even though I don't know who Maciej is or what Rails app he's actually written. I think you should use a tool you're reviewing for a project before making up your mind about it.
When debating with people online, I have to be caustic and biting (although not too much) to be taken seriously.
People like it when you appear to have no sacred cows and call out things which might otherwise be thought hip or something.
I'm frightened by such an uniform behavior in the YC community. By dismissing any dissenting point of view you kill diversity. I remind you that the next fad you (and I) will be trying to catch will be created by a guy bothered by the current state of things. Bothered enough to act (and reunite the "Tipping point" conditions).
This guy attack RoR, he's attacked personally as trying to sound smart. Have you ever criticized anything ?
(my karma will follow the Dow Jones today I think ....)
At least that's my take on it. Slinging numbers like 100 and 0 is generally a sign of hyperbole.
Java makes programming difficult. Some people like that. Many don't.
Ruby makes programming easier. RoR makes doing webapps easier. This guy's premise, that there is no overarching philosophy to RoR, is incorrect, and shows unnecessary ignorance and anger. You have to wonder if he's just projecting.
My problem is that I'm tired of all these articles proclaiming "Skub considered harmful"[1], "Why Skub sucks", "Skub on rails sucks!" or "Skub ruining CS degrees".
But it just goes round and round and round.
Someone says something bad about Skub then another 6 blog posts pop up defending it and how the author is a douche. Then it just burns through the blog-sphere like a wildfire before burning out. Ready to start again!
Rails is not a solution for: "create the most well engineered product possible."
Rails is a solution for: "solve this business problem with these limited resourced in this limited time frame as inexpensively as possible. Oh and we're not sure exactly what the business problem is, we'll need to see a few prototypes before we are able to figure it out."
The amazing thing about rails is not how good it is. The amazing thing is how much better it is than most solutions in spite of how bad it is.
Rails is a success because it was created by someone who has a real understanding of economics, business value, and resource limitations. Not because it's a brilliant piece of engineering.
This premise is wrong, so I almost TLDR'd the post immediately. I decided to skim further, though:
"And to stress the first point again, Rails never concerns itself with the big-picture problem of 'writing webapps.' It only thinks as big as 'outputting HTML strings' and 'querying the DB for a list of things.'"
This is provably false. The average reader of the intro chapter of most Rails books could tell you that, for example, Rails enforces high-level application design patterns like Model-View-Controller, thus exposing his statement as factually untrue. The guy seems to have languages like PHP (or, charitably, Ruby) confused with the Rails framework. Nice try by the OP, but ultimately an unconvincing troll.
Rails is certainly not the be-all and end-all of web design. Lately it seems to be the 'cool' thing to bash Rails, but I'm not sure that that's warranted either. It seems to be a backlash against all the hype that Rails has generated along the way.
Time will tell whether or not Rails will become a piece of timeless software or if it will simply fall to the wayside.
Until then, go forth and write great software!
Ezra Z has made Merb, a lighter and arguably cleaner version of core Rails (minus AR, etc), if you're bugged by Rails core code.
Could you shed a little light on why you feel that way?
If you are building an Ajax/Flex rich client, particularly one that can work offline, you'd want the state on the client-side. Then you could view the server in a very RESTful way while handling program flow in your client app. Under these circumstances, there's less of a win with continuations.
Among the advantages in imposing a RESTful architecture on your server, the most interesting to me is the way that your server becomes a bunch of resources on which you can do a very limited set of things (the HTTP verbs). It imposes an easily understood interface, which is nice if you (or others) write other apps to access your server.
One of the big advantages of statelessness is that it scales wonderfully. REST aligns itself with HTTP very nicely. Continuations are a clever compromise between highly stateful applications and stateless HTTP.
Ajax and Flex turn your browser into a smart client of sorts, and I think that a RESTful service design can stand independent of any particular client. It allows for many different clients to interact with your service besides just your particular Ajax web page. In that sense continuations would be perfectly suitable in those situations where you need to keep track of state. RESTful services need to stand independent of a particular client front end.
Anyway, I think that those principles are complementary and should work well together. Ajax (or some other rich client technology) on the front end and REST on the back.
Hmm. I think I may try my hand at writing a small web framework in Lua... that's been kicking around in my head lately.
The point I agree with him the most is that "different parts of Rails are accessible at different stages of processing the request". This one annoyed the hell out of me, it took me forever to solve the problem of adding your own custom configuration options and accessing them from anywhere in the app.
We computer science guys, and especially those with background in maths, always want to have frameworks reduced to orthogonal concepts that recombine in all possible ways to create very diverse outcome. This leads to algebraic-type formal systems that are very beautiful and powerful in their domains.
You can rarely model a real-world domain in such a minimalistic and mathematical way. Think about it: if it was easy and useful, the natural languages we used would benefit a lot from being unambiguous, minimalistic and mathematical. We have neither evolved to use such languages nor successfully created ones outside narrow artificial domains This, I think, is an important lesson for computer science.
Recently we have seen the rise of Perl, and later RoR. Why are they successful, despite having fuzzy concepts and leaking abstractions? I think this is because they try to mimic natural languages, and put the mathematical clarity aside.
Perl's author is a linguist and had consciously borrowed natural language characteristics: http://www.wall.org/~larry/natural.html DHH has emphasized a lot that he wants his DSLs to look like natural languages (don't have a reference right now). Perhaps this means something.