There’s a shitty API and it’s ruining your day. What do you do?
Without making a moral judgment, I want to remark that there is something very different about these two approaches. In Dropbox’s case, Dropbox has no (direct) influence on what APIs Apple provides for its operating system. So it has no choice but to work within the boundaries of the existing API. (When Apple says jump, you say, “How high?”) But in Adam’s case, POSIX is implemented by an open source project Linux, and with some good ideas, Adam could implement his new interface on top of Linux (avoiding the necessity of writing an operating system from scratch.)
Read more...
One of the early posts from this blog, from 2010, was on the subject of how to pick your string library in Haskell. Half a decade later, the Haskell ecosystem is still largely in the same situation as it was half a decade ago, where most of the boot libraries shipped with GHC (e.g., base) still use the String type, despite the existence of superior string types. The problem is twofold:
Read more...
A common claim I keep seeing repeated is that there are too many language-specific package managers, and that we should use a distribution’s package manager instead. As an example, I opened the most recent HN discussion related to package managers, and sure enough the third comment was on this (very) dead horse. (But wait! There’s more.) But it rarely feels like there is any forward progress on these threads. Why?
Here is my hypothesis: these two camps of people are talking past each other, because the term “package manager” has been overloaded to mean two things:
Read more...
When building a module system which supports parametrizing code over multiple implementations (i.e., functors), you run into an important implementation question: how do you compile said parametric code? In existing language implementations are three major schools of thought:
- The separate compilation school says that you should compile your functors independently of their implementations. This school values compilation time over performance: once a functor is built, you can freely swap out implementations of its parameters without needing to rebuild the functor, leading to fast compile times. Pre-Flambda OCaml works this way. The downside is that it’s not possible to optimize the functor body based on implementation knowledge (unless, perhaps, you have a just-in-time compiler handy).
- The specialize at use school says, well, you can get performance by inlining functors at their use-sites, where the implementations are known. If the functor body is not too large, you can transparently get good performance benefits without needing to change the architecture of your compiler in major ways. Post-FLambda OCaml and C++ templates in the Borland model both work this way. The downside is that the code must be re-optimized at each use site, and there may end up being substantial duplication of code (this can be reduced at link time)
- The repository of specializations school says that it’s dumb to keep recompiling the instantiations: instead, the compiled code for each instantiation should be cached somewhere globally; the next time the same instance is needed, it should be reused. C++ templates in the Cfront model and Backpack work this way.
The repository perspective sounds nice, until you realize that it requires major architectural changes to the way your compiler works: most compilers don’t try to write intermediate results into some shared cache, and adding support for this can be quite complex and error-prone.
Read more...