A language in which you can't conditionally hot-patch other people's code requires modifications to happen upstream. Thus technical debates become political debates between the constituencies of multiple incompatible forks of "the" ecosystem. Version hell times fork wars.
The question is: who maintains the old APIs? You or someone upstream? If the language somehow makes every change "breaking", suddenly, that becomes tens of APIs, not just a couple. And if the community lacks consistent standards, that's only more work to maintain those forks.
-
-
Anyone could feasibly maintain old APIs, though ease depends on package system. Security fixes can be back-ported for years, or transition packages could implement old APIs in terms of new APIs to better follow updates. There are many related PL design issues, of course.
-
I'm not suggesting that Guix and Nix are substitutes for good language design. Rather, that fork-and-merge is a viable and interesting basis for design of a PL ecosystem. New PLs can be designed with Guix or Nix in mind instead of conventional npm, NuGet, hackage, or crate.
- 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
Read my blog!