Another libraries vs frameworks

So frameworks provide functionality above your code, and libraries provide functionality below your code; it's better to be limited below than above; thus we should use libraries more than frameworks.

It's an argument I've come around to recently, but what I'd really like to see is some investigations of what styles of though can lead to functionality that is "scaffolding" for other code. That doesn't just provide a floor or a ceiling, but that provides a ladder that you can hang more code from. A simple example is Lisp conditions: they provide a hook in the code you can attach things to, instead of just providing a baseline to code off of. Event-based systems are another good example (whether this is a Javascript-like model, or a Emacs-like hook model). After all, the event model of HTML gives you enormous flexibility on handling events.

So here's a language-design question: what's a language we can talk about hooks in? How can you make a hook-based model maintainable? Is there any way to make hooks implicit (like advice --- though advice seems to still require too much internal knowledge to be maintainable if used everywhere).

Maybe an Erlang-like model where you have servers pass messages, but you add the opportunity to intercept messages? If the messages are fixed-format, they'd hopefully be well-defined enough for the whole system to be maintainable. And if you need security, you can use all of the now-well-known methods for authenticating and encrypting messages. (And hopefully the vm you're running on can make it cheaper than actually encrypting.)

But that seems like the sort of insufficient creativity endemic of Hacker News posts at 5AM. How do we do better? Or

I guess frameworks have their use cases. For example, now that you mentioned it, the EventEmitter on node.js is a framework-kind of model where your code is invoked when a certain condition is met. They seem to have done it beautifully. In fact the whole runtime (environment) is event driven, so I like to think of my application as a user of the node.js framework. However, many a times when coding higher level requirements or ever-changing business requirements, frameworks tend to lose their way and programmers land up writing around the restrictions.

I guess it makes sense to have a framework when you know the requirements in & out and you know that they are not going to change (like low-level I/O or socket or FS stuff which has remained the same for years now), and a library otherwise.

And like anyone who's ever tried to build a large front-end application with _just_ a library (jQuery) will tell you: it quickly gets way out of hand and completely unmanageable before the product even releases.

One the same note, if all you need is a quick animation when a button is clicked, and some extremely trivial dynamic elements on the page, a large framework like Sproutcore is going to just get in your way, and you'll spend more time trying to learn how the hell to use the damn thing and twist it into doing a task that's outside of its primary purpose.

In short: use the right tool for the job. The anti-framework posts to come out of the woodwork this morning on HN are pretty disheartening. I sincerely doubt anyone that's completely against using a framework has ever written a large application that they need to support, that didn't end up as a giant mess of spaghetti code stringing libraries together haphazardly.

I'd be more interested yet if it were possible to fire your own IO events and such --- so that you could replace the top levels of the framework, and use the remainder as a library. So that instead of spreading your code like jelly on a pre-built slice of bread, you instead layer your code and library/framework code as you see fit, into a delicious cake.