On Thu, 3 Jan 2008 13:51:33 -0500, Giles B. wrote:
One of my biggest gripes about Rails, and I see this a lot, is that it
doesn’t completely encapsulate the lower layer; that’s not its goal. It
makes the easy things easy.
I think that’s actually a strength. It’s not like you can really get
away with just learning Rails. Rails is like a gigantic set of
power-user shell aliases that make common use cases simple, clean, and
powerful. But if you want to get anything done, you still need Unix. I
think that’s actually really what made Rails successful.
I completely agree with your disagreement of my statement!
Not to get all dualistic on you, but every strength is a weakness,
every
weakness is a strength. (Well, for most values of “every”.)
A couple of years ago, I thought I was smart because I finally
understood
the difference between “satisficing” and optimizing. It wasn’t till
recently that I realized that satisficing is optimizing - by including
the cost of doing the further optimization. (Now, of course, that’s
apparently so obvious that it’s the second sentence in the Wikipedia
article. I sweartagod it wasn’t obvious to me then.)
Needing to drop below Rails is a strength (it doesn’t have to be
everything
to everyone) and a weakness (it doesn’t do everything for anyone).
To me, not being clear about when you will have to drop below Rails is
a
further weakness; Rails is attractive because of its simplicity, which
means it attracts people who don’t know what they don’t know. Now
that’s
not a Rails problem, or even a beginner problem; it’s a human problem.
Still, the less you need to know to do something, the less you will know
about the world it exists in.
The very same arguments people use about “write your own authentication
system so you know what it does” can be extrapolated to “write your own
framework” - and, from there, to “write your own language”, “build your
own
computer”, and “don’t believe anything you haven’t seen with your own
eyes”. It’s all of a piece.
Conversely, there’s a good argument that not protecting developers
themselves is a strength. They’ll learn from it, they’re free to
experiment, and frankly it makes the framework easier to create, which
makes it quicker to release, which makes it more likely to be popular.
Etc.
Rails is, in essence, a really useful metaphor for design. Like all
metaphors, it has limits; like all metaphors, you can confuse the
attributes of the metaphor with the attributes of what that metaphor
represents. At that point, it’s not useful anymore.
The key is being able to know how far you can push your metaphor. Rails
isn’t a general-purpose tool. Nothing is. There is exactly one type of
general-purpose tool in the universe: an atom. They’re hard to work
with.
Personally, I’d like to be able to push Rails farther than I currently
can.
Personally, I wish Rails was just protective enough so you knew when you
were puncturing the metaphor. But I do recognize the strength of those
weaknesses.
(In an utter coincidence, I will be starting a new blog at
www.useful-metaphors.com shortly, talking about all this kind of stuff.)
