Michael C. Libby wrote:
> ...
> 
> Part of the problem we have with Ruby is that writing new code that is 
> fairly powerful is very, very easy. This is a good problem to have. :)

Quite true.  Often  it takes far less time to just write the code than
to figure out someone else's API.  I found this to be the case recently
on a Rails app.  I reached a point where it was not at all clear if
Rails could do what I want, or do it efficiently, so I just rolled my
own from there on.

> 
> Of course, this also means that it might be easier to simply code from
> scratch than figure out how to extend existing complex code. With Ruby
> this is less of a problem than some languages, but big projects are 
> still big projects... and that can be intimidating (at least to me).

What I would like to see more of (and mind you this is likely a
reflection of my awareness of the state of Ruby apps and libs than
anything else) are easily-decomposable frameworks, or, better yet,  many
small, well-defined, lightweight libs that may be assembled into a
framework.    Code where you can write the entire API on an index card.

For example, Rublog has, I believe, code that lets you feed off content
stored in CVS.  That alone is quite interesting, outside of any specific
application.  If I wanted that in another application, I could grab the
source for Rublog and hack out that part, or reinvent it, but, ideally,
I could code grab some standalone code and just use that.

(This is not a roundabout plea for Dave Thomas to actually do this, just
an example that popped into my head.)

If I were to knock a common feature of many frameworks, it is that they
put too much in one bundle.

But the reality may be that evolving cleanly decoupled code is often at
odds with Getting Results(tm).

Maybe, in the long run, as various Web framework efforts live or die,
there will be some fallout of additional simple but practical libraries
that others can use to wire up into another application.

James