Damian Conway on Perl and its future

Re:Damian Conway on Perl and its future by elblanco on Tuesday May 25, 2010 @05:47PM (#1378740)

While I think CPAN is a fantastic resource (I wish other languages had something even half as good as CPAN for a centralized repository of various libraries and other odds and ends), it's not a standard library, it's a collection of libraries. While PPM is sweet, I work on lots of systems that are not connected to the Internet, and believe me, not having a guaranteed minimum standard library can be a serious PIA. Most distros do at least come with a set of stuff installed by default, which is nice, but it also is not the same as a standard library since that loadout might change from distro to distro, or version to version.

Basically the standard Perl library are whatever functions Perl happens to have. Which, while amazing for text processing, don't help much with other needs.

[ Parent | on HN ]

Re:Damian Conway on Perl and its future by avar on Tuesday May 25, 2010 @06:13PM (#1378814)

Any standard library is a collection of libraries. While I get your point, mine is that different languages have different ways of handling libraries, with different tradeoffs. Perl's way is to make it really easy to get libraries over the network, instead of trying to ship a large collection of them with the core.

A standard library, I think. Is what you go look for when you need a module to solve your problem. With Java that's [1], with Python that's [2]. With PHP (until somewhat recently) that was using one of the ~1200 built-in functions.

With Perl, the place to go for libraries is the CPAN. I look at http://search.cpan.org, not `perldoc perlmodlib` if I need a library to do X.

There are cases where this is painful, such as offline machines. But in those cases you can pack all of CPAN on a CD (with minicpan), or produce a self-contained Perl program + libraries with local::lib and/or PAR.

1. http://java.sun.com/javase/6/docs/api/ 2. http://docs.python.org/library/ 3. http://perldoc.perl.org/perlmodlib.html

[ Parent | on HN ]

Re:Damian Conway on Perl and its future by loewenskind on Wednesday May 26, 2010 @04:02AM (#1379786)

This is exactly why perl is moving out of the big orgs (at least everyone I've worked at in the last 5 years, and I'm a contractor). Getting anything on a production system is a hastle. Using a language like python that just has most everything out of the box is much easier than something like perl where I need to make a hundred different requests to be able to do any big project.

EDIT: And your CD suggestion is a good way to get sacked.

[ Parent | on HN ]

Re:Damian Conway on Perl and its future by draegtun on Wednesday May 26, 2010 @04:28AM (#1379820)

I see and think the complete opposite on this (and I'm also a contractor).

Like a lot of things in working life it depends on where you're coming from and where you are but I find Perl much easier to maintain across multiple servers because of CPAN (especially by using internal mirrors... for eg. minicpan) than with some other languages.

[ Parent | on HN ]

Re:Damian Conway on Perl and its future by elblanco on Tuesday May 25, 2010 @10:22PM (#1379328)

> There are cases where this is painful, such as offline machines. But in those cases you can pack all of CPAN on a CD (with minicpan), or produce a self-contained Perl program + libraries with local::lib and/or PAR.

Which is pretty much what I have to resort to :(

I don't have to do this for the most part with Java or Python.

PAR is good for deployment, but obviously hard for offline development work (sometimes you just have to do the work on those machines).

Thanks for the pointer to minicpan. I might give that a shot, might save me from manually mirroring CPAN.

[ Parent | on HN ]