
A brief history of CPAN - smegel
http://cpan.io/ref/history.html
======
cstross
A point for non-Perl folks looking at this on HN: While the use of a minor
version number might suggest to you that Perl 5.20 is just a bugfix/update
from Perl 5.6, that's very much not the case -- in most other language
cultures it'd be several major version numbers on and be seen as a vast
improvement over the earlier release.

The problem for this is that the name "Perl 6" was reserved a long time ago
for what has become essentially a different language -- bearing about as close
a relationship to Perl 5.x as C++ bears to C. So Perl is stuck with minor
version number increments, from 5.6 (which IMO should have been Perl 6) to
5.20 (which equally well might be called Perl 20).

~~~
smacktoward
_> which equally well might be called Perl 20_

That was my thought, too -- they should just do what Java did and drop off the
"major" version number altogether. In 2014 it confuses more people than it
helps.

~~~
cstross
I believe there is just one obstacle to doing that: Larry.

(Perl isn't the product of a corporate culture: it's a labour of love.
Unfortunately this can result in some quirky ego-related side effects.)

~~~
kbenson
I don't think it's fair to lay all the blame for any current blockage on
Larry. I think the same issues that apply with just using Perl 7 as the name
of the next version apply to just using the secondary version number.

It also ignores the validity of the underlying assumption of this line of
reasoning, that Perl would be more popular and more used if only the version
number was 7.3 or something else that suggested change. I think there's enough
holes to be addressed in that argument that making changes based on it is
really just flailing in the dark, twiddling bits hoping for a better outcome.

~~~
cstross
It's not that Perl would be more popular and used if only the version number
changed -- it's that the not-obviously-iterating version number fools people
who don't look closely at it into thinking the language is moribund.

(This problem was a major topic of coffee stand discussion at YAPC::NA this
July ...)

~~~
kbenson
I have have a feeling it's been a major topic of discussion at quite a few
YAPC::NA's that past few years. It was in at YAPC::NA in 2013.

My question is, _what_ people is it fooling?

If the person is unfamiliar with Perl, 5.20 isn't going to mean anything to
them, since they have no reference. If the person is familiar with Perl and
remembers something about the version they used, 5.20 is different than any
version number they remember, so denotes some change they may choose to look
into. If the person is familiar with Perl and doesn't remember the version
they used or hasn't heard from any other possible source there's been same
major changes, then a major version number change may attract their attention,
but will it do so any more than the numerous announcements about major changes
with versions that are announced? I'm not certain, and even if it does, is
catering to this small subset of people worth it? I'm even less certain.

If the language is to grow, it needs new blood, not just to draw back
expatriates. I think the name argument is just a red-herring drawing people
away from action that could actually be of use (IMHO, virtually any other
action).

------
mhd
Having to fight with the node.js package-space just increased my appreciation
for CPAN, its content and users. Perl might never had much luster and got
slightly outpaced by other scripting languages within the last few years, but
it's got a _very_ solid foundation, unlike e.g. Tcl.

Managing projects with perlbrew and carton is pretty convenient, and you're
free to choose between old-style modular development or various object
systems, both lite and heavy, with syntactic sugar or not (recent discovery:
Moops).

~~~
davidw
What is 'unsolid' about Tcl? I'll take its source code any day over Perl's.

~~~
SwellJoe
I've worked pretty heavily in both. I don't think Tcl is clearly superior, as
a language, to Perl. And, certainly the CPAN is vastly more impressive and
vital than the ecosystem around Tcl. One of the reasons I gave up on Tcl was
because there just weren't enough people working in it to keep the libraries
moving forward (and our website, built on OpenACS, was suffering for it).

So, since we're talking about CPAN, I'd say that the library and development
ecosystem around Tcl is "unsolid" where for Perl it is pretty impressive. It's
only relatively recently that Python and Ruby have reached parity with CPAN,
even.

~~~
davidw
> Perl might never had much luster and got slightly outpaced by other
> scripting languages within the last few years, but it's got a very solid
> foundation, unlike e.g. Tcl.

Was the phrase, though. I don't think anyone really questions whether CPAN is
better than what Tcl had, and you can debate what you like about both
languages, but to call Tcl unsolid is not very accurate, in my opinion.

~~~
SwellJoe
I assumed what he meant by "the foundation" was the libraries and culture,
which Perl demonstrably has gotten pretty right, while Tcl hasn't. If the
foundation is everything you build your projects on top of, then Perl has a
vastly better foundation. If the foundation is _just_ the language itself,
then Tcl is pretty good.

So, I see where you're coming from if speaking only of the language itself.
Tcl is a quite nice, well-thought-out, language. It has a few quirks, but so
does Perl.

~~~
mhd
Yes, that's what I intended to say. Maybe "foundation _s_ " would've been
clearer.

The first two of which would probably be the language design itself and the
implementation. I'd rather not argue about the former, and regarding the
latter I don't have a lot of experience with Perl, although I've heard that
it's gotten better once they awoke out of the post-Perl6 slump. Still, Tcl was
always pretty great in that regard.

But as we're talking about the CPAN here, a lot of the alternatives come out
short-handed, and Tcl amongst them. I remember the days when you had a
different interpreter for every extension...

------
ceronman
Many thanks to the Perl community for CPAN! Having an easy to access
repository of reusable libraries has given us more power to develop cool stuff
than any specific language features. That's why nowadays every important
programming language has some sort of CPAN clone.

~~~
peterwwillis
Hopefully some day they can expand to support all the functionality added onto
CPAN, like PAUSE, cpantesters, BackPAN, CPANTS, Test::*, TAP, CPANPLUS,
local::lib, cpancover, cpanratings, cpanminus, Perlbrew, Carton, Pinto,
minicpan, Metacpan, CPAN RT, AnnoCPAN, etc. You can go right now and find the
test results of building whatever module you want on whatever perl you want on
whatever platform you want, find ratings and user comments, and see general
quality ratings of a module distribution's construction.

The only problem I have with CPAN is its lack of a past. You can't just re-
download some module from CPAN you had installed a year ago, because it got
removed from CPAN and now it's on BackPAN, so now you have to cobble together
some scripts to download all the correct dependencies from BackPAN, and use
Perlbrew to get the right perl version + core, and use Pinto to maintain your
archive of old modules for the branch/release of your application that it
matches. Maybe this is a problem that every language's library repositories
have, but it's annoying that there isn't a CPAN standard for "install only the
dependencies of module X at the time Module X was released".

~~~
perigrin
`cpanminus` should install from BackPAN automatically if you ask for an
explicitly older version. `cpanfile` and Carton do a fairly decent (IME YMMV)
job of locking versions.

~~~
peterwwillis
Indeed, and Pinto uses cpanminus. Carton, however, does not work well with
mod_perl type systems, since you have to 'carton exec' your apps.

The whole thing is still a mess, though. For example, some dists never got put
into CPAN at all; they were either one-off releases or were shipped in a Linux
distro or a perl core at some time or another and then re-versioned for CPAN.
So when you try to find the source via cpanminus, you can't, because it
literally doesn't exist. So you can either upgrade or downgrade and face
whatever incompatibility that means, or use perlbrew and maintain your entire
perl stack for every app you ship. Unfortunately it turns out Pinto has a slew
of bugs that require you skip all errors (ick). Let's face it, versioning and
releases in Perl modules is a goddamn wilderness.

------
nanoscopic
Something missing from the history is the existence of the "categorical tree"
for CPAN modules, the existence of "registered modules", and the recent
destruction of both of these features, primarily due to lack of people
maintaining CPAN ( Brian D Foy got overloaded ).

The interface doesn't show any difference currently between modules that were
just thrown up willy nilly and those that went through community discussion
and review.

It could be useful to mention some of the various binary distribution systems
in existence pulling from CPAN ( such as Activestate )

One of the sources for some of the information is very interesting though:
[http://history.perl.org/PerlTimeline.html](http://history.perl.org/PerlTimeline.html)

------
Animats
Python needs something like CPAN. Python has Cheese Shop (now called PyPi).
It's just a link farm; it doesn't host the modules. Nor does it have any
useful curation. So there's no quality control, and no way to fix anything
short of forking a new version.

That's the big advantage of CPAN. CPAN is the de facto owner of the modules in
CPAN, and those modules can be maintained.

~~~
autarch
> That's the big advantage of CPAN. CPAN is the de facto owner of the modules
> in CPAN, and those modules can be maintained.

This is just false. The CPAN maintainers (really PAUSE maintainers) can
transfer ownership of modules away from totally AWOL owners, but it's not like
this happens all the time.

There's plenty of bitrot on CPAN because the original owner went AWOL and no
one else has been motivated enough to ask to take the module over. There is no
"CPAN group" who maintains modules.

~~~
Animats
No, but at PyPi, nothing gets maintained, just replaced. There are about five
modules for parsing RFC3339/ISO8601 dates (the format that appears in every
email) and they're all broken, but in different ways.

------
mzs
The link to 'PAUSE history' requires a login.

~~~
fuzzix
[http://pause.perl.org/pause/query?ACTION=pause_06history](http://pause.perl.org/pause/query?ACTION=pause_06history)

Pull request on the way.

------
dang
Url changed from [http://blogs.perl.org/users/neilb/2014/08/a-brief-history-
of...](http://blogs.perl.org/users/neilb/2014/08/a-brief-history-of-
cpan.html), which points to this.

