Created: May 08, 2020
Modified: May 08, 2020
Modified: May 08, 2020
write libraries, not frameworks
This page is from my personal notes, and has not been specifically reviewed for public consumption. It might be incomplete, wrong, outdated, or stupid. Caveat lector.- In software: a library is a collection of tools. You can use some or all of them, in combination with other tools. A framework, on the other hand, is a world you live in. It is tightly coupled--if you use some of it, you probably need to use all of it.
- A framework is opinionated. It chooses a way to do things, and therefore it's not compatible with other ways those things could be done.
- From Write libraries, not frameworks: frameworks are a much bigger responsibility. In a framework you have the user captive. It's like having a rabbit in a box. It's your job to anticipate the rabbit's every need. If you provide it with air and water but forget that it also needs food, the rabbit dies. Similarly, a framework isn't useful unless it satisfies all requirements.
- Another way to put the difference is in terms of inversion of control. With a library, the user calls the library code. In a framework, the framework calls the user code.
- Meanwhile, libraries are useful even if you don't commit to them. A library provides building blocks. You can use some or all of them, but you don't have to commit. If there's a flaw with some part of the library, it's fine. Just don't use it.
- Frameworks can be useful. They provide limitations; limitations can reduce complexity. If your box is set up with all of your needs, it can be very comfortable. But: the scale of the responsibility is such that you can't build one yourself. Building frameworks is a project for large teams, for tech companies.
- In areas I know about:
- numpy and scipy are libraries.
- keras is somewhere-in-between. It does build its 'own world' of model specifications. But you can generally use it with lower-level TF ops.
- Edward2 is a library, in that you can use it to build log-joint functions. But when adding interceptors, it becomes a framework.
- PPLs are inherently frameworks because you have to specify a model and control its execution. You have to box in the user's code a bit, because it's not ordinary code.
- But. Living within Python and TF/Pytorch free you from doing everything. And TFP exists as a library. Distributions and bijectors are great.
- As a design principle, you maybe want your PPL to have the minimal frameworkiness and maximal librariness.
- In TFP, JDs are little 'frameworks' but then they encapsulate the model within a much larger library. Building small interoperable components was always NameRedacted's maxim, and now I understand it better.