5 ms·

And perl solved that perfectly: just let the OS/distro solve the 100s of packages. And it have been solved, despite you claiming otherwise on your last paragrap

by gcb0 7y ago

And perl solved that perfectly: just let the OS/distro solve the 100s of packages. And it have been solved, despite you claiming otherwise on your last paragraph. When did you have to use cpan in a modern system? Compare that to how many times you had to use pip. Now, if you use a crappy OS or distro (or god forbid, some container built by you have no idea who on top of nobody knows what) then yeah, you are bound to do the leg work yourself, but you will be doing that regardless of the language/subsystem you are trying to use in that case. Not to mention that it is the only way to do things professionally. For example, if you must have a system that parses XML but for company policy is not allowed to have even the means of performing a network request. With python you either have both xml and an http library and whatever else included and you will either have to do a special package with a striped down python+xml only or get a corporate exception. While on other languages you can install only the xml parser component package and your code will run happily and be compliant with company policy.

majewsky 7y ago
> When did you have to use cpan in a modern system? Compare that to how many times you had to use pip. Well yeah. A sizable amount of new software is still being written in Python. But when I use Perl software (besides my custom scripts), it's always stuff that's old enough that the distribution is carrying packages for it. If you disagree, please name a significant new software written in Perl that was released in the last, say, 5 years.
- gcb0 7y ago
  name one package you missed in those 5 years. I see your comment as the goal, not the problem.
thaumasiotes 7y ago
> if you must have a system that parses XML but for company policy is not allowed to have even the means of performing a network request. With python you either have both xml and an http library and whatever else included and you will either have to do a special package with a striped down python+xml only or get a corporate exception. While on other languages you can install only the xml parser component package and your code will run happily and be compliant with company policy. ...wouldn't the company policy involve removing the means of performing a network request from the computer, making the notional capabilities of the software irrelevant? Python will let you drive network requests through the OS. It's just that you wouldn't normally want to.
- lalaland1125 7y ago
  +1 for this. Trying to ban programming languages that support network connections is both foolish and impossible. Any Turing complete language that allows any sort of OS interaction can be used to communicate over a network. Even if you have to manually do the syscalls yourself.
- gcb0 7y ago
  most companies i've worked for have special packages for perl/python/php/etc that compile the interpreter without support for system calls, for example. That alone have probably paid of handsomely over the years considering all the XSS we patched, which could very well have been full network compromises.
walshemj 7y ago
You use CPAN all the time in perl develpment
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
__david__ 7y ago
I use cpan constantly, though indirectly via carton. I used to use the OS for Perl libs but this starts to fail hard when you have multiple projects that all demand different versions of stuff.

by gcb0 7y ago

majewsky 7y ago

> When did you have to use cpan in a modern system? Compare that to how many times you had to use pip. Well yeah. A sizable amount of new software is still being written in Python. But when I use Perl software (besides my custom scripts), it's always stuff that's old enough that the distribution is carrying packages for it. If you disagree, please name a significant new software written in Perl that was released in the last, say, 5 years.

gcb0 7y ago
name one package you missed in those 5 years. I see your comment as the goal, not the problem.

thaumasiotes 7y ago

> if you must have a system that parses XML but for company policy is not allowed to have even the means of performing a network request. With python you either have both xml and an http library and whatever else included and you will either have to do a special package with a striped down python+xml only or get a corporate exception. While on other languages you can install only the xml parser component package and your code will run happily and be compliant with company policy. ...wouldn't the company policy involve removing the means of performing a network request from the computer, making the notional capabilities of the software irrelevant? Python will let you drive network requests through the OS. It's just that you wouldn't normally want to.

lalaland1125 7y ago
+1 for this. Trying to ban programming languages that support network connections is both foolish and impossible. Any Turing complete language that allows any sort of OS interaction can be used to communicate over a network. Even if you have to manually do the syscalls yourself.
gcb0 7y ago
most companies i've worked for have special packages for perl/python/php/etc that compile the interpreter without support for system calls, for example. That alone have probably paid of handsomely over the years considering all the XSS we patched, which could very well have been full network compromises.

walshemj 7y ago

You use CPAN all the time in perl develpment

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

__david__ 7y ago

I use cpan constantly, though indirectly via carton. I used to use the OS for Perl libs but this starts to fail hard when you have multiple projects that all demand different versions of stuff.