A brief history of CPAN
cpan.io
cpan.io
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).
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.
(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.)
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.
(This problem was a major topic of coffee stand discussion at YAPC::NA this July ...)
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).
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).
But you need more than one leg to stand on, and due to its embedded roots and other hysterical reasons, Tcl did a relatively bad job when it came to building a good package library and infrastructure. Which in turn hurt the community, which made for fewer package contributors and so forth.
And once Tk lost most of its importance and languages like Lua appeared...
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.
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.
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.
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...
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".
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.
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
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.
Pull request on the way.