13 ms·

Interesting. Is this because the Perl ecosystem is more mature or because of the philosophy of backwards compatibility? The "backwards compatibility" philosoph

by berntb 10y ago

Interesting. Is this because the Perl ecosystem is more mature or because of the philosophy of backwards compatibility? The "backwards compatibility" philosophy isn't so explicit for the ecosystem, mostly the language? Is the test-on-install-by-default making a big difference there?

bandrami 10y ago
That's a good question. I think it's not a coincidence that CPAN predated the widespread use of distributed source control systems whereas pypi and gems blew up just as mercurial and git were unseating svn and cvs. It's a different release philosophy (remember, in the 1990s you often didn't even get to see pre-release CVS commits of open source projects; that was an innovation of OpenBSD). I also think the widespread use of VPSs rather than accounts on shared servers (again, containerization) was a factor. In the 90s and early 2000s, you usually (even in a corporate setting) had an unprivileged account on a server with a given version of apache and perl, your own cgi-bin directory, and possibly some latitude on a personal CPAN install directory. The lack of containerization meant you had to compromise between using newer software and breaking existing use cases. So I guess I think it's not so much about Python vs. Perl per se but about the technologies available when those languages became popular among developers.
rootusrootus 10y ago
That would seem to be ironic. As a longtime Perl developer who switched (for pragmatic reasons -- a job) two and a half years ago, my impression is that Python [as a language] is much better suited to a business environment. What makes Perl such a wonderful language and why I enjoy it so much is exactly why it blows as a business language. Python's rigidity is very useful if you ever want someone else to read and understand code written by someone else. So the idea that Perl ends up with the more mature package management is exactly the opposite of what I would have predicted. That said, I haven't had any more problems with PyPi packages than I did in the past with CPAN. Yes, pip always wants to upgrade itself, but that sort of every-damn-day software upgrade cycle seems to have become quite prevalent, not just in the Python world.
- berntb 10y ago
  You talk about that Python have just one possible layout standard and so on, I guess? That is a different subject. (And sure, no coding standard is bad for a project, Python removes that discussion to a degree.) I think the real problem with Python/Ruby/etc is the surprising lack of an analogue to CPAN Testers. It isn't just all of CPAN that is tested on different OS/Perl version combinations, it also stress test the Perl versions.

by berntb 10y ago

bandrami 10y ago

That's a good question. I think it's not a coincidence that CPAN predated the widespread use of distributed source control systems whereas pypi and gems blew up just as mercurial and git were unseating svn and cvs. It's a different release philosophy (remember, in the 1990s you often didn't even get to see pre-release CVS commits of open source projects; that was an innovation of OpenBSD). I also think the widespread use of VPSs rather than accounts on shared servers (again, containerization) was a factor. In the 90s and early 2000s, you usually (even in a corporate setting) had an unprivileged account on a server with a given version of apache and perl, your own cgi-bin directory, and possibly some latitude on a personal CPAN install directory. The lack of containerization meant you had to compromise between using newer software and breaking existing use cases. So I guess I think it's not so much about Python vs. Perl per se but about the technologies available when those languages became popular among developers.

rootusrootus 10y ago

That would seem to be ironic. As a longtime Perl developer who switched (for pragmatic reasons -- a job) two and a half years ago, my impression is that Python [as a language] is much better suited to a business environment. What makes Perl such a wonderful language and why I enjoy it so much is exactly why it blows as a business language. Python's rigidity is very useful if you ever want someone else to read and understand code written by someone else. So the idea that Perl ends up with the more mature package management is exactly the opposite of what I would have predicted. That said, I haven't had any more problems with PyPi packages than I did in the past with CPAN. Yes, pip always wants to upgrade itself, but that sort of every-damn-day software upgrade cycle seems to have become quite prevalent, not just in the Python world.

berntb 10y ago
You talk about that Python have just one possible layout standard and so on, I guess? That is a different subject. (And sure, no coding standard is bad for a project, Python removes that discussion to a degree.) I think the real problem with Python/Ruby/etc is the surprising lack of an analogue to CPAN Testers. It isn't just all of CPAN that is tested on different OS/Perl version combinations, it also stress test the Perl versions.