

Rails is 100% magic with 0% design  - twism
http://groups.google.com/group/comp.lang.lisp/msg/f2c33661b80ba302

======
carpal
This is mostly bullshit. The guy is trying to do things in Rails the _wrong
way_ and complaining about it failing. He does have a few legitimate points,
but I guess I'll go at it point by point, because it is fucking long:

-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...](http://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#M000936)

It helps if you read the fucking documentation before you criticize something.

~~~
granderson
the parent post is dead on. the guy who wrote the article does not know rails
well enough to find accurate criticisms.

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.

~~~
cglee
I'll throw my 2pesos in as well and concur here. Though I do feel the pain of
traversing down the call stack to dig up where the magic is. Ruby for Rails
has a great chapter on digging into Rails core code which helped me a lot.

------
robmnl
A lot of this is really a rant, but I do agree with some of it:

"- 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.

~~~
DarrenStuart
amen, if you are coming at it with no other coding experience then I would
think its a breaze. my main problem is when you start to dig you feel like
alice in wonderland going down the rabit hole.

------
davidw
It's easy to piss on things after the fact. It is pretty common behavior in
our field to try and make yourself look good by criticizing others' work. It's
usually pretty easy to find things to pick on with the benefit of hindsight,
but much harder to create something new.

~~~
nraynaud
Well, imagine this rant where "RoR" would be replaced by "java", wouldn't you
imagine being the author of the pamphlet ?

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 ....)

~~~
davidw
Uhm... I actually wrote my programming language, Hecl, in Java. While there is
a lot I don't like about Java, I still don't like the tone of these kinds of
articles. I think after a while you can sniff them out - when they're really
trying to point out some deficiencies, and when they're just going for a boost
by putting stuff down.

At least that's my take on it. Slinging numbers like 100 and 0 is generally a
sign of hyperbole.

~~~
chaostheory
I agree instead of bitching about Rails, the guy should be writing about why
Weblocks is so great - with more detail than: "because they actually stopped
and thought about the whole thing for a moment, and try things that will
address the problem as a whole"

------
davidmathers
This guy is trying to apply rails as a solution to the wrong problem space. No
wonder he finds it wanting. Typical.

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.

------
pius
_"There's no overarching design or scheme of things, it's just a bucket of
tools with some glue poured in."_

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.

~~~
LogicHoleFlaw
MVC, while a valuable application design principle, is not really tied to
'writing webapps.' The article mentions things like the stateless nature of
HTTP requests, which are very much bound up in the idea of writing software
accessible over the web. Something like Seaside (a Smalltalk framework for
developing web apps) is much more aligned with the request-response cycle that
is the web. It uses the continuations feature of Smalltalk to map that cycle
into a natural language idiom. Neat.

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!

~~~
DocSavage
The Rails team has thought a lot about the stateless nature of HTTP requests,
and they've pushed for a RESTful style of handling things (e.g., the REST
architecture described in O'Reilly "RESTful Web Services" book). Seaside (and
Weblocks) seem to focus on continuations, but I'm not convinced this is the
way to go, particularly with richer Ajax and Flex clients.

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.

~~~
LogicHoleFlaw
Oh definitely. I didn't mean to imply that the Rails team hasn't thought about
things like REST. They are huge proponents of that design philosophy.

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.

~~~
pstuart
Lua has been on my "todo" list for a while. Looks like there's already a
framework out there:

<http://www.keplerproject.org>

------
bfioca
Even if every point the author makes is true - there are still plenty of
reasons why you _should_ use rails in many cases. The first of which I'd argue
is you can get shit done fast! For startup founders, this is essential. Make
something. Put it in front of users as fast as possible. See what they like
and dislike. Fix it. Repeat. Rails makes this super fast and easy. Once you
get to the point where you really care about any of the things this guy
mentions, hire a team to rewrite it. You'll need to at some point anyway...

------
tx
Huh... that's harsh, and is coming from more knowledgeable Rails hacker than I
am, I wasn't aware of this mess with :union and :group in AR, while I don't
mind Rails' habit of passing around hashes of options.

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.

~~~
thomasfl
Have you tried some of the other ruby frameworks, like merb? Merb is not that
different from rails, but seems to perform better and can be used with other
ORM's than ActiveRecord as well.

~~~
tx
When we started nearly two years ago, we had to quickly drop Windows and
simultaneously learn Linux/bash, vim, Ruby, Rails, Apache, SVN plus million
other things in a hostile and unknown land of old :-))) No, I have not heard
of Merb back then, we compared RoR against PHP and went with Rails and so far
it wasn't a bad ride. The key to NOT be disappointed is to do everything
"Rails-way", i.e. treat DB as a dumb swamp where you keep your models. So far
so good.

~~~
mechanical_fish
I'm pretty sure Merb didn't exist two years ago, so I wouldn't be too ashamed
that you didn't hear of it back then. :)

------
ntoshev
He is right in most of his critics.But, worse is better.

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.

------
damon
Come on, it has a pretty obvious design. So obvious in fact that Microsoft is
copying it for "asp.net" v-next. There is a lot of magic to rails, but let's
call it "configurable magic" since __it seems__ most of the magic can be
overridden (i'm not a pro). But to say it doesn't have a design? Come on...

<http://www.asp.net/downloads/3.5-extensions/>

~~~
DarrenStuart
I am looking forward to the next release, this one ain't great. MS MVC should
go further than rails and will no doubt scale without much hassle. I wish they
would just do a standard release of ruby.net in visual studio. yeah there is
Ironruby but not the same as a fully supported release like C sharp, vb.net
and J sharp.

