3 ms·

I don't mean OS distributors can't package up CPAN modules. They can do that, no problem, same for the Python equivalents. I mean that a significant use people

by avar 7y ago

I don't mean OS distributors can't package up CPAN modules. They can do that, no problem, same for the Python equivalents. I mean that a significant use people get out of Python and Perl is that they aren't bare-bones like say Scheme or Lua where the standard library is really spartan. It allows you to write useful code that works on the lowest common denominator of "just OS Perl or Python". Whether that's some random version on whatever Linux distro, or *BSD or Solaris or whatever without needing to write your own getopt library or whatever. Which is why the "let's ship a bare-bones compiler and have people use CPAN or PyPi" is contentious. In theory it shouldn't matter, and for a lot of shops who install hundreds of packages it doesn't, but it does for people who target stdlib-only, which is a big use-case. Particularly since the people who have that use-case are drawn to these languages.

dragonwriter 7y ago
> Which is why the "let's ship a bare-bones compiler and have people use CPAN or PyPi" is contentious. But you don't have to ship just a bare-bones interpreter to deal with the problem of stdlib staleness, you just need the stdlib libraries to be updatable via package manager, you don't need to not ship a baseline version of them with the interpreter. That doesn't deal with the bloat issue raised with relatively unused libraries, but if they are relatively unused because they aren't good rather than because the use case is uncommon, upgradability could solve that. Of course, you don't solve compatibility for versions before the move to upgradable packages, but at the same time if you solve problems going forward you increase the incentive to upgrade.
- avar 7y ago
  Sure, in Perl these are called "dual-life" modules. It makes things easy for users, but makes the life of the compiler-maintainer worse. Now not only do they need to ship a stable compiler+large-stdlib, but they can't even rely on there being a 1=1 version relationship between the two, instead it'll be many=many as users might use multiple library versions with multiple compiler versions.
  - dragonwriter 7y ago
    > Sure, in Perl these are called "dual-life" modules. It makes things easy for users, but makes the life of the compiler-maintainer worse. Well, yeah, but you're not going to have much of a language at all if you optimize for quality of life of the language maintainer.

by avar 7y ago

dragonwriter 7y ago

> Which is why the "let's ship a bare-bones compiler and have people use CPAN or PyPi" is contentious. But you don't have to ship just a bare-bones interpreter to deal with the problem of stdlib staleness, you just need the stdlib libraries to be updatable via package manager, you don't need to not ship a baseline version of them with the interpreter. That doesn't deal with the bloat issue raised with relatively unused libraries, but if they are relatively unused because they aren't good rather than because the use case is uncommon, upgradability could solve that. Of course, you don't solve compatibility for versions before the move to upgradable packages, but at the same time if you solve problems going forward you increase the incentive to upgrade.

avar 7y ago
Sure, in Perl these are called "dual-life" modules. It makes things easy for users, but makes the life of the compiler-maintainer worse. Now not only do they need to ship a stable compiler+large-stdlib, but they can't even rely on there being a 1=1 version relationship between the two, instead it'll be many=many as users might use multiple library versions with multiple compiler versions.
- dragonwriter 7y ago
  > Sure, in Perl these are called "dual-life" modules. It makes things easy for users, but makes the life of the compiler-maintainer worse. Well, yeah, but you're not going to have much of a language at all if you optimize for quality of life of the language maintainer.