3 ms·

I think it was CPAN that killed Perl, at least that was a major nail in the coffin for me. I have no idea what the CPAN of today is like, but back in the mid-l

I think it was CPAN that killed Perl, at least that was a major nail in the coffin for me. I have no idea what the CPAN of today is like, but back in the mid-late 90's it was horribly unreliable. There were dozens, if not hundreds of modules that did the same thing, and a lot of them had major bugs. But installing one was the big issue, as it would always choose the latest release of any module in the dependency chain, including the perl interpreter itself. And this was done without any hint as to whether the module actually worked with the latest versions of those modules. So, you'd end up upgrading a bunch of modules, very likely breaking things that worked. And at the end, it'd "upgrade" the perl interpreter. And by "upgrade" I mean install a new copy, replace all OS references to the new version, but not include any of those modules you just installed. So you had to re-install everything again. Perl's main use at the time was developing CGI scripts. It had big disadvantages over things like PHP and Netscape Commerce at the time, but people still seemed to like Perl. As complex web side code grew more complex, requiring a lot of 3rd party components to get Perl to do anything, people seemed to abandoned it pretty quickly. I still use Perl today, version 5. Mostly just to process text files, but I still don't use any 3rd party libs.

cestith 7y ago
There are many tools for installing modules. Almost all of them default to the latest available package but can be told a version. I suggest looking into local::lib and then either a combination of cpanm and a Cpanfile or using perlbrew.
ether_at_cpan 7y ago
> But installing one was the big issue, as it would always choose the latest release of any module in the dependency chain, including the perl interpreter itself. You are mistaken. No cpan client is capable of upgrading perl itself. If a cpan module declares a dependency on a perl version later than what you are currently running, the installation simply fails (as what would happen if there is a dependency declaration on a module that is shipped with core and is not upgradable separately, e.g. 'strict' or 'POSIX').
- gmiller123456 7y ago
  Maybe that's how it is today, but every time I installed a module in would invariably end with CPAN downloading the source of the latest build, compile it, and install it. Then I'd have to go and re-install every module under the new version.
- Grinnz 7y ago
  Well, not strictly mistaken, but severely outdated. The CPAN module did try to upgrade Perl in ancient versions, and this of course was a terrible idea.
- peteretep 7y ago
  This is true now, but was not true many years ago.
  - Grinnz 7y ago
    To put some numbers in this thread, it was fixed in CPAN.pm version 1.90 in 2007, which first came with Perls 5.8.9 and 5.10.0 (but can be updated on older Perls).
wott 7y ago
> I have no idea what the CPAN of today is like, but back in the mid-late 90's it was horribly unreliable. There were dozens, if not hundreds of modules that did the same thing, and a lot of them had major bugs. Well, the main change is that between then and now, other languages have setup modules depositories / package managers which are even more of a mess, so in comparison CPAN doesn't look bad any more. :-)

cestith 7y ago

There are many tools for installing modules. Almost all of them default to the latest available package but can be told a version. I suggest looking into local::lib and then either a combination of cpanm and a Cpanfile or using perlbrew.

ether_at_cpan 7y ago

> But installing one was the big issue, as it would always choose the latest release of any module in the dependency chain, including the perl interpreter itself. You are mistaken. No cpan client is capable of upgrading perl itself. If a cpan module declares a dependency on a perl version later than what you are currently running, the installation simply fails (as what would happen if there is a dependency declaration on a module that is shipped with core and is not upgradable separately, e.g. 'strict' or 'POSIX').

gmiller123456 7y ago
Maybe that's how it is today, but every time I installed a module in would invariably end with CPAN downloading the source of the latest build, compile it, and install it. Then I'd have to go and re-install every module under the new version.
Grinnz 7y ago
Well, not strictly mistaken, but severely outdated. The CPAN module did try to upgrade Perl in ancient versions, and this of course was a terrible idea.
peteretep 7y ago
This is true now, but was not true many years ago.
- Grinnz 7y ago
  To put some numbers in this thread, it was fixed in CPAN.pm version 1.90 in 2007, which first came with Perls 5.8.9 and 5.10.0 (but can be updated on older Perls).

wott 7y ago

> I have no idea what the CPAN of today is like, but back in the mid-late 90's it was horribly unreliable. There were dozens, if not hundreds of modules that did the same thing, and a lot of them had major bugs. Well, the main change is that between then and now, other languages have setup modules depositories / package managers which are even more of a mess, so in comparison CPAN doesn't look bad any more. :-)