Hacker News new | ask | show | jobs
by pavpanchekha 5456 days ago
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

1 comments

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.

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.