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.
-
-
Replying to @Ngnghm
Guix and Nix package managers, which are designed for reproducible builds, essentially have the effect of making it easier, cheaper, and more politically acceptable to fork and merge the ecosystem. MVCC/DVCS update patterns instead of shared global state.
1 reply 0 retweets 2 likes -
Replying to @awelonblue
True, but often forking is the relatively cheap part. Maintaining the fork is the expensive part, especially if thou shalt not miss critical security fixes among a sea of noise from constant breaking changes in umpteen dependencies. At the wrong end of the spectrum: npm.
1 reply 0 retweets 0 likes -
Replying to @Ngnghm
Security updates are a valid concern, but I would generally address them elsewhere in language design (cf. object capability languages or algebraic effects). They're also the exception, not the rule. Most 'maintenance' is new features or behavior, which can safely be deferred.
2 replies 0 retweets 0 likes -
Replying to @awelonblue @Ngnghm
Behavior changes may include lesser bug-fixes. But most bug-fixes also don't require breaking changes to an API, thus do not hinder merging of changes.
1 reply 0 retweets 0 likes -
Replying to @awelonblue
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.
1 reply 0 retweets 0 likes -
Replying to @Ngnghm
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.
1 reply 0 retweets 0 likes -
Replying to @awelonblue @Ngnghm
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 reply 0 retweets 1 like
Well, I for one am certainly using Nix as my packaging environment, wrapping around Gerbil Scheme's native gxpkg. To scale, you also need community standards and best practices, but the Gerbil community is small enough that our gitter channel is enough for now.
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!