|
|
|
|
|
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 |
|
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.