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).
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.
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.
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 ...)
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).
`perl -v` even goes so far as to say "This is perl 5, version 20, subversion 0". The addition of "v5.20.0" immediately after doesn't sync up very well with that though.
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).
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.
> 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.
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.
Yes, that's what I intended to say. Maybe "foundations" 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...
Don't get me wrong, I'm not trying to Stallmann the language itself, I've always enjoyed working with Tcl. And as you say, it's got a pretty great source code.
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...
Tcl's package/repository story was certainly inferior to Perl's, and many other languages'. That's different from the language not being 'solid' though!
I love Tcl. It is the quirkiness (meaning non-Algol) of it that appeals to me. The community around it is great. The TCT puts a lot of thought into what goes in as well. I am on the dev list to just keep an eye on what goes on. :)
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.
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".
`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.
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.
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 )
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.
> 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.
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.
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).