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".

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".

That's a strong claim. Exactly what qualified it as "dependency hell" for you. What problems did you run into?

Like depending on 20 other modules, 4 of which fail to build with the current version. Lots of bitrot.

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

or

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.