Re: The tension between transparency and abstraction, and some links


By Josh Adams.

There’s a comment at the bottom of this article that strikes me as a good example of the circumstances that led to Rails’ ease of use / maintenance:

I’ve struggled with this issue too.

I haven’t come to any concrete conclusions either other than to emphasize that abstraction *costs*.

And not only does it cost, but it usually costs *more* than we think it does – because the person designing the abstraction is not the same person who has to invest the effort to learn how the abstraction works later on.

I think this is one of the main reason why the überframeworks fail. When you try to build a framework in a vacuum, separate from a real application that uses the framework, you clearly don’t have a good grasp of the costs of the abstractions you’re creating.

So I think whenever we create new abstractions we need to make sure we have very good reasons for doing so, and that we’re not unwittingly creating more trouble than we’re solving.

The fact that Rails is being developed by a company currently making money off of products written in it has led to a better framework, I believe.

Finally, let me just spew out some great links:

That is all…


One Response to “Re: The tension between transparency and abstraction, and some links”

  1. There have been a few threads on this recently:

    Joe Gregorio: Knowledge Acquisition

    Bill Higgins (me): application begets framework

    PS – Thanks for the link to my Ajax and REST article and I’m glad you got something out of it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: