Thursday, June 22, 2006

Frameworks versus Libraries

Benji Smith, who is famous for why he hates frameworks, has very good points.

(Go read that.  it's important, and it'll make you a better person.)

His points about the problems with abstraction in frameworks are good, and well taken.  (at least, they're well taken by me.  It seems like the Java EE folks and the WS-* folks have a lot to learn from him.)  But a couple of posts down in that thread he comes back with some more ideas, one of which is one I really wish I'd thought of first:  the difference betwen a framework and a collection of libraries.  The difference is this:  your code encloses its libraries, but is enclosed by its framework.  This has a couple of consequences that are good for framework vendors, but bad for developers:

1. frameworks are mutually exclusive.  If you're using Java, you're by definition not using .Net; if you're using Struts, you're not using JSF; if you're using Google Web Toolkit, you're not using Atlas; if you're using GTK, you're not using QT.

2. frameworks impose lockin.  In order to stop using a framework, you have to get your code out of it, a process that may or may not be possible and certainly won't be easy.  In order to stop using a library, you have to take the library out of your code.  Depending on how heavily you're using it, that might be hard too; but in its hardest case, you still don't have to "get your code out of" a library. 

The difference is crucial.  The barriers to exit are much, much lower with libraries than with frameworks.  Developers of libraries have to be a lot more humble than developers of frameworks do; we talk about "J2EE applications", but not about "cURL applications" or "pango applications".  Given the choice between a framework and a library with equivalent functionality and ease of use, I'll take the library every time.

Of course, libraries and frameworks still have a lot of similarities.  They're both bits of helper code that purport to do something complex or common well, so you don't have to hand code boring or tricky things.  They're programs like everything else, with a tradeoff between features and complexity.  They have their bugs, and their idiocies.  And there are certainly times when it makes sense to use a framework; Ruby on Rails or PHP or JSP or ASP is better than coding servlets or CGI programs, for the majority of the things I want to expose on the web.  But when you evaluate some helper code, be aware of the difference between a framework and a library.  And when you're *writing* helper code, for gods' sake please write a library.  Frameworks are much harder to get right.

Friday, June 02, 2006

The Wisdom of Crowds

Tim Bray on Tantek Celik on Scott Reynen on the topic of innovation, using a turn of phrase Bill Joy invented:  "Innovation happens elsewhere".  I take Tantek's (and Bill's) point:  there's more brainpower on the internet that there is in your walled garden, sure.  And the 'net will do as the 'net wills, that's for sure.  If you're trying to do something that the 'net can do, you're better off letting the 'net do it.  (Things the 'net can do:  make a half-decent operating system for operating system nerds, generate impenetrably abstruse discusison on every topic known to humankind, expose failures of thought quickly, etc etc.)

But there are things the 'net can't do.  And, contrary to the opinions of the 'net, not all of those things are uninteresting by virtue of the fact that the 'net can't do them.  One of them is good usability, for example.  The 'net's greatest downfall is its greatest virtue:  anyone can participate.  Sure, bad decisions get questioned, but so do good ones.  The 'net builds consensus, and relies on the assumption that what "everybody knows" is what's right.  And for most things, it is.

But not for everything.

Anything that's counterintuitive, the 'net's going to get wrong most of the time.  Anything that's profoundly multidisciplinary, the 'net's going to get wrong most of the time (because the experts in the individual fields will drag the project their way, at the expense of the others).  I'm sure there are other examples.

I think we haven't got the balance right between hierarchical, corporate, power-concentrating decision making and the wisdom of crowds here at Sun.  We're still too focused on the hierarchy; we don't do enough out in the open where people who care can keep us in check.  But it's possible to go too far the other way, too, and get mired in endless debates about what the right thing to do is.  What we need, of course, is the Platonic benevolent-dictator philosopher-king; someone everyone trusts, who takes good advice and ignores bad advice, who listens when it's appropriate and rules by fiat when it's not.  (and while I'm making wishes, I'd like a pony.)