4 ms·

"But it's not unique anymore. And it no longer brings anything truly amazing to the table that you can't find in a competitor language." Name another multi-par

"But it's not unique anymore. And it no longer brings anything truly amazing to the table that you can't find in a competitor language." Name another multi-paradigm language with as broad, deep and well-tested library as CPAN. "Unless a miracle happens, it will never return to dominance in anything other than niche domains (like quick-n-dirty commandline scripts)." When has "dominance" (whatever that means) or popularity ever been the goal or desirable? I can't think of any language or system that is universally "dominant"; all have niches to work. You don't get into programming because you want to do what all the cool kids are doing. Paul Graham (you might have heard of him, you're using his site) argued very well on the advantages of choosing above-average tools for above-average results. (http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html)

TylerE 15y ago
Having dealt with CPAN, I'll take python and pip _any day_. CPAN is practically the definition of dependency hell. For developers it may be good (I don't write Perl, so I dunno), but for end users it's a real clusterfrak.
- Mithaldu 15y ago
  That's a strong claim. Exactly what qualified it as "dependency hell" for you. What problems did you run into?
  - TylerE 15y ago
    Like depending on 20 other modules, 4 of which fail to build with the current version. Lots of bitrot.
    - Mithaldu 15y ago
      If i am understanding you right, you are talking about modules being abandoned and not working with a newer perl version you installed? In that case that is most certainly not dependency hell, since no amount of dependency gyrations could fix it. The module is flat out broken on that version. Perl does however give you all the information you need to figure out on which versions of Perl the given modules work via: http://matrix.cpantesters.org/?dist=IO-Socket-SSL-1.49 http://matrix.cpantesters.org/?dist=IO-Socket-SSL-1.49 or http://www.cpantesters.org/distro/I/IO-Socket-SSL.html#IO-Socket-SSL-1.49 http://www.cpantesters.org/distro/I/IO-Socket-SSL.html#IO-So... Armed with that knowledge you can then use Perlbrew to install that version and be on your way. If i misunderstood, please feel free to correct me.
- ojosilva 15y ago
  The only dependency hell I've had installing modules in my 14 years of programming with dynamic languages was trying to get 2 different Rails apps to work out of the same gems... Ruby, my other favorite language besides Perl, is just as vulnerable to dependency problems as... every other language! Ruby, Python, Perl, Java, they all have lots of packages and modules that depend on each other. So do many Linux distributions. Dependency hell is not language nor domain specific. After all these years, one of the reasons I stick with Perl and CPAN is precisely because I can monitor and anticipate dependency problems with CPAN Testers. MetaCPAN has nice impact analysis tools too. I'm yet to find something comparable in any other language ecosystem. Hell, you can't even specify a minimum version of a module to import in Python, like in Perl's "use Module 2.3".
  - Mithaldu 15y ago
    Honestly, i'm fairly sure he just plain doesn't know that "dependency hell" means "can't install stuff because of conflicting or circular dependencies"; but thinks that the term means "well them sure are a lof of deps, yup".

TylerE 15y ago

Having dealt with CPAN, I'll take python and pip _any day_. CPAN is practically the definition of dependency hell. For developers it may be good (I don't write Perl, so I dunno), but for end users it's a real clusterfrak.

Mithaldu 15y ago
That's a strong claim. Exactly what qualified it as "dependency hell" for you. What problems did you run into?
- TylerE 15y ago
  Like depending on 20 other modules, 4 of which fail to build with the current version. Lots of bitrot.
  - Mithaldu 15y ago
    If i am understanding you right, you are talking about modules being abandoned and not working with a newer perl version you installed? In that case that is most certainly not dependency hell, since no amount of dependency gyrations could fix it. The module is flat out broken on that version. Perl does however give you all the information you need to figure out on which versions of Perl the given modules work via: http://matrix.cpantesters.org/?dist=IO-Socket-SSL-1.49 http://matrix.cpantesters.org/?dist=IO-Socket-SSL-1.49 or http://www.cpantesters.org/distro/I/IO-Socket-SSL.html#IO-Socket-SSL-1.49 http://www.cpantesters.org/distro/I/IO-Socket-SSL.html#IO-So... Armed with that knowledge you can then use Perlbrew to install that version and be on your way. If i misunderstood, please feel free to correct me.
ojosilva 15y ago
The only dependency hell I've had installing modules in my 14 years of programming with dynamic languages was trying to get 2 different Rails apps to work out of the same gems... Ruby, my other favorite language besides Perl, is just as vulnerable to dependency problems as... every other language! Ruby, Python, Perl, Java, they all have lots of packages and modules that depend on each other. So do many Linux distributions. Dependency hell is not language nor domain specific. After all these years, one of the reasons I stick with Perl and CPAN is precisely because I can monitor and anticipate dependency problems with CPAN Testers. MetaCPAN has nice impact analysis tools too. I'm yet to find something comparable in any other language ecosystem. Hell, you can't even specify a minimum version of a module to import in Python, like in Perl's "use Module 2.3".
- Mithaldu 15y ago
  Honestly, i'm fairly sure he just plain doesn't know that "dependency hell" means "can't install stuff because of conflicting or circular dependencies"; but thinks that the term means "well them sure are a lof of deps, yup".