From: Jay Levitt <jay+news@...>
Date: 2008-01-04T09:20:05+09:00
Subject: Re: Zed Shaw - Ruby has dodged a bullet

On Thu, 3 Jan 2008 13:51:33 -0500, Giles Bowkett 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.)

-- 
Jay Levitt                |
Boston, MA                | My character doesn't like it when they
Faster: jay at jay dot fm | cry or shout or hit.
http://www.jay.fm         | - Kristoffer