On the version number succeeding Perl 5
Recently Ovid broached the topic of allowing a future release of Perl 5 with a version number greater than 6; this is not a new argument. He further explicated the problems:
I just got back from FOSDEM and heard, again, for the umpteenth time, that since Perl had 4 “major” releases (1,2,3,4) in its first few years and hasn’t had a major release since Perl 5 about 20 years ago, it’s clearly “dead”. I hear this every time I go to a conference that’s not dedicated to Perl.
…
Meanwhile, in the minds of, of, virtually every developer on the planet who’s not in our echo chamber, Perl 6 is, logically, the successor to Perl 5. Since even Duke Nukem Forever managed to get released prior to Perl 6, Perl 6 just isn’t being taken too seriously be many devs. In other words, they think Perl 5 is dying and its successor is DOA.
I agree with him. As I commented:
I think Perl 5 has had to live in the shadow of Perl 6 for too long. Now that its decided that they will be two different languages, I think its only fair to allow Perl to get the cache’ one gets from a major version increment.
This can end the “Perl is dead” chatter (outside the community anyway). After all why would you want to use Perl 5 when Perl 6 is going to replace it (says Joe Pythonista or Jane Rubyist).
Perl 7 is here! Its Plack and Catalyst/Dancer/Mojolicious(+Mango (what’s Mango?)), its Moo(se)? and DBIx::Class. Its CPANtesters and MetaCPAN and cpanm. There is so much the outside world has missed because they are waiting for Perl 6, which may come at some point but it still wont replace Perl 5. Lets show them its safe to come back and that there are LOTS of goodies to find when they do!
That said I want to take it even a little further. Perl has been proud of its backward compatibility, and well it should be! Code from many years ago runs well on very recent Perls. But what can be a blessing can also be a curse.
Perl 5 still supports many conventions and oddities from Perl 4 and before. There are some silly things like ' as a package separator, which most people neither use nor trip over. Then again there are some real things, like indirect objects notation, default script/handle encoding, new keywords.
Olof Stockhaus made a compelling case that Perl 5 might want to use the jump to Perl 7 to make some breaking changes. For example, among other things he suggests waiting for the p5mop project. However, I think I agree with Damien Krotkine in saying that that sounds like a great target for Perl 8 which could come soon afterwards. There are many things we wish for a future Perl, but until they are ready, there still could be some changes. I think Perl 7 could be a great oportunity to do minor, but important, breaking changes. Then let Perl 8 come in later with a MOP or a proper language spec. Either way, without a major version increase its hard to make breaking changes. Without a major version to increase, we have been stuck.
Now, some have suggested that we should drop the 5 from the version number and add it to the name. Therefore we would have Perl5 version 20.0 and Perl6 version 0.1. The problem is that this still doesn’t make the case that Perl6 won’t supplant Perl5. Those people like to make the case that Java dropped the 1 so that Java 1.6 became Java 6. However this comes back to my first point. They realized that 1.5 and 1.6 (or whatever was the actual change) was going to have major changes and should be a major release. Why they didn’t simply call it Java 2 I’m not sure. What I do know is that they weren’t trying to convince people to use Java1 version 6 when something called Java2 existed.
To comment on using the year as the version number I think there are two problems with that. First, it doesn’t really signify that Perl6 is not the successor. Secondly, what it does seem to signify is that the Perl community is going to abandon the stability that is one of its strongest suits. Yes I’m advocating some breaking changes above, but rather small ones, things that will help more than they hurt to fix. I don’t think we want to imply that there will be breaking changes once per year, we can still use feature to scope changes to Perl 7 through sub-major version releases. That said, breaking changes once a decade is probably ok.
Perhaps this is the root problem. The semantics of versioning are an important tool to inform the outside world what the state of Perl is!
Anyway here’s what I propose. Say we do implement the above, so now we have two languages Perl5 and Perl6. However, since Perl5 version 20 is mostly compatible with Perl version 5 perhaps it could be allowed to keep the name. Then it seems odd that Perl should jump versions from 5 to 20, so why not just move to the next available number 7. So now we have Perl 7 successor to Perl 5 and Perl6 a new language.
This does not signify the death of Perl 6 but the life of Perl. It just so happened that Perl 6 became its own language and started its own branch in the Perl family tree. Now that we know that the success of Perl 5 and Perl 6 no longer depend on each other, why should their version numbers?
After the break, my initial list of realistic goals for Perl 7
To be worthy of a breaking release, here are some things that I would want to see for a Perl 7 release. Note that I’m assuming that most of these things are already implemented and that new big niceties would be targeted for Perl 8.
- strict and warnings on by default
- autodie (or at least parts of it) on by default
- as much of the recent unicode work, plus unicode scripts and unicode handles on by default (think
use utf8::all, and theunicode_features) - the proven keywords/additions from
featureenabled by default - a final change in smartmatch behavior (and given/when) or removal
- a final change in refs as array/hash or removal
- remove
'as a package separator - add Moo as a core module, unless of course people want full-blown Moose
- dare I say “remove CGI.pm” from the core?
Things I would like for Perl 7
- remove indirect object syntax (or at least
no indirectby default). This would likely mean special casing (s)?print(f)? - my personal favorite,
return @arrayandreturn ( <list> )behave the same in scalar context (whichever way) (maybe this is too advanced, and thus should be for Perl 8)
Do you have any others? I’m sure there are more to come!
As I delve into the deeper Perl magic I like to share what I can.
There was a Java 2. It was version 1.2, and it was where Sun put in all the stuff they intended to get done for the first version but ran out of time.
Anyway, I agree with the basic premise, if only so I can stop seeing “Should I learn Perl5 or wait until Perl6?” questions popping up now and then.
I love this idea.
I would definitely add in the list of things to ship in Perl 7: include Moo or Moose by default. I think it’s very important to have a proper object system available without having to install it from CPAN. My personal inclination would be Moo, because it’s lighter and faster and properly morphs to Moose classes if needed. But really, any decent OP would do.
I knew I had forgotten one, yes I think adding Moo to the core is a great idea.
Perl 6 may not be the successor, but Larry got (unofficial?) dibs on “Perl” name. I remember him saying a few years ago that he doesn’t want to rename Perl 6.
And rebranding Perl 5 as Perl 7 leaves Perl 6 in the same disadvantage as the one Perl 5 is in now.
Better organization and cleanup of the standard library. If I want to get the canonical path of some file or directory, I need to use the aptly-named Cwd module. File::Spec and File::Path, which one can append directories in a cross-platform way? File::Basename does very little and could probably be absorbed by one of the other File::* modules.
By contrast, python’s standard lib is well-organized and nearly all-encompassing. I’d settle for well-organized (CPAN works because it’s a constant battle for supremacy. 2 solutions enter, 1 solution leaves!)
Removal of the function categories “SysV IPC” (put them in a module) and “Fetching User and Group info” (unless that one works on more than just Unicies).
A couple of the other function groups could be relegated to core modules with little impact.
@Vyacheslav Matyukhin, while I know Larry gets the final say in some of this, I think this way: if Perl 5 has no more followers by the time Perl 6 comes around, who is likely to use it. Perl 5 needs to maintain some traction in the world if Perl 6 is going to have a chance. Sadly the names are slowly killing both. All I suggest is naming it
Perl6rather thanPerl v6.@preaction, those sound like nice cleanups to target, how easily could they be implemented? You’ll notice that essentially all of my proposed changes are already in place and in fairly wide use. Additionally most can be lexically reverted easily. I like modularizing some SysV functions, but can it be done easily, correctly and mostly backward-compatibly?
This sounds fantastic. Ditch cpan and include cpanminus in core. Some people have also expressed interest in a better build system (like Dist::Zilla) in core as well.
There are some problems with including Dist::Zilla. The first is that it is an author tool, not a build tool and as such it is not needed in the core for use by most users. Second, the module itself isn’t prohibitively large, but many authors use a large number of plugins which almost certainly couldn’t be core; this argues for remaining on CPAN. Third and most importantly, it relies on Moose, and until that is core, no Moose-dependent modules can possibly be.
I’m not sure what the actual dependencies for cpanminus are, but I do know that it relies on an external data source more than do the other common clients, which would make it an awkward add to the core.
All that said, Moo(se)? in the core, and a more streamlined CPAN client would be excellent additions.
Joel : I don’t see why using year in version means dropping backward compatibility. That said, I think yearly version naming is probably better suited for “distributions” (be it Linux, or anything that is a bunch of packages). I would actually like to see frozen versions of CPAN that are fairly stable, and released as CPAN 2013.5. Which cpanm (bundled by default with Perl 7) would point to, by default.
Hi
I fear there is no easy answer to these questions.
But first a warning: I believe that preserving back-compat is not /always/ the highest goal. Fixing design faults (more above and below) can justify a new version which breaks back-compat.
Changing the version # for marketing reasons - i.e. to influence community perceptions - may be a good idea, but I have great doubts, given the mentality of Perl’s (external :-!) critics.
Of course it will be sneered at as an attempt to cover up problems, in the same way that Perl will be attacked for breaking back-compat.
Likewise, Perl will be attacked for /not/ breaking back-compat, i.e. not adopting newer ways of doing X and Y.
Also, the issue of numbering is not the same as the issue of what to include in newer versions.
Above, ‘preaction’ referred to Cwd and File::* (out of many such possible discussions). Let’s think about this.
I could argue that their roles be handled like this (warning: don’t jump to conclusions!): 1) Rename File::chdir to Path::chdir 2) Absorb some of their functionality into Path::Tiny and/or 3) Transfer such funcationaly to other Path::* namespace modules.
Do you see? The content of future Perls, and their breaking or not of back-compat is complex, given that we could have a long, non-definitive argument about this one small (joke) item.
Alternately, if historical design mistakes are preserved, why change the numbering system?
As for that, I wouldn’t mind Perl 6.1, 6,2, etc alongside Perl 5 becoming 13 (as in 2013), 14, etc. That way, neither sequence treads on the toes on the other one.
So, what to change?
Personally, I’m in favour of ditching indirect object syntax and all (or most :-) of the other tacky barnacles which encrust this amazing language.
As for additions: cpanm of course, *::Tiny (with a few exceptions, e.g. my Config::Tiny::Ordered!), Moo, even Moose.
But we need a definitive list of what can be chopped, not a useful but grab-bag of suggestions from a range of people. Actually, I’d like to see as much as possible chopped, but there may be good reasons for not doing that.
The other set to chop are modules which we somehow (shudder) agree are badly designed…
So, is anyone collating arguments for and against (i.e. in a wiki) what to do?
In lieu of Perl 5.x and Perl 6.x I think converting to a code-name branding would help achieve what you seek. Certainly version numbers would be present, but the public face would be the code-name similar to Android OS versions [1].
Perl Camel anyone?
[1] http://en.wikipedia.org/wiki/Android(operatingsystem)#UsageshareofAndroidversions
Great work is already happening with perl5i: https://metacpan.org/module/perl5i
Method Signatures or similar must be included for consideration in any future evolution of Perl 5: https://metacpan.org/module/Method::Signatures
@dams, I’m not saying that year-versioning would actually mean breaking compat yearly, I’m saying it might LOOK like we are doing that.
@Ron, if you’ll notice, hardly anything I suggest in a Perl 7 is really breaking, its more like changing the defaults. In this case getting current code to run might involve such simple things as
no strict; no warnings; no utf8; use indirect;etc. These are things that many people fault us for now, and also things that many people already do by default, or else get some package to do for them, i.e. Modern::Perl or else have a package import for them, i.e. Moose or Mojo::Base.These are incremental changes that could be easily made if only we felt like breaking Perl 4(!) compatiblility, and change to some more modern defaults. Other than a real MOP and better concurrency what other better ways of doing X/Y should we add? The newest Perls have some of the best support for unicode in the programming world, just turning THAT on by default would benefit Perl and bring some wanted attention!
Why all the hate on CGI.pm? Don’t like it, don’t use it.
I don’t think my arguments were that compelling and I definitely wasn’t clear enough about what I meant when I listed what I thought should go into Perl7 core.
What I meant was that the mop and the signatures should be included in some future release of Perl 7, not specifically in 7.0. All the things that breaks backwards compatibility needs to be in the first release though.
As to what numbering scheme to use: My problem with yearly numbers is not that it can be look like we’re breaking backwards compatibility, it’s that it will not be possible to tell when we do.
The only scheme that I can think of that will change that is to combine the suggested schemes as follows:
Rename the language from Perl to Perl5
Set a new major version E.g. v20 and keep it until we break backwards compatibility again
Use the release year as minor version
Keep the patch version scheme as today.
I.e the releases would be called:
Perl5 v20.2014.0 First release according to this scheme
Perl5 v20.2014.1 first patch
Perl5 v20.2015.1 next minor release
Perl5 v22.2017.0 next major release?
I don’t know how well this would play out marketing wise though, but I think we could get away with it without stepping very hard on Larry’s toes.
I couldn’t login to chromatic’s blog to comment on his post about it so I’ll reply here in hope that he may read it.
The version number matters because it’s a mental barrier for breaking backwards compatibility and cleaning up the core. As long as we’re on major version 5 there will be a strong opposition against breaking backwards compatibility so we need to find a way to step the major version to get rid of the mental block.
Olaf: I also couldn’t log into chromatic’s blog.
I don’t hate CGI.pm, what I hate is that new Perlers find some ancient code or tutorial that uses it and think that its how you write new webpages in Perl. By the time they show up at StackOverflow or elsewhere and ask about some issue, they have spent far too long learning an outdated technology.
In my vision they now install Perl 7. Type
use CGIand it dies. They google for CGI and see the announcement that Perl 7 has been released and it drops CGI, because its not the recommended new technology.You could still install it from CPAN, and it would still run (given some minor changes pursuant to the other things on my list. But at least it gives them reason to stop and consider if there is a
betternewer option.Hi
To Olof@here.and.now: A version number like ‘Perl5 v20.2014.0’ is a bureaucrat’s dream. Many Perlers (not me, tho) love abbreviation. So, no thanx.
To Joel@here.and.now: I omitted a couple of huge points in my last post. Sorry: (1) Perl 5., etc would maintain back-compat. Perl 6. is a different language (i.e. should(?) break back-compat). And Perl 7.* should definitely break back-compat. That would be the point of its existence.
(2) Where is the (wo)man-power? If it was available, why hasn’t it been employed on Perls 5 or 6?
There is simply not enuf human effort to support these 3 streams of Perl. So I expect things to continue as before.
Despite the massive effort that has gone into Perl 5, I’d like to see future effort go into Perls 6 and 7.
“To comment on using the year as the version number I think there are two problems with that. First, it doesn’t really signify that Perl6 is not the successor.”
I think this gets at the actual social problem behind all these renaming schemes, which is that none of us want to thumb our noses at the work on the Perl 6 project: we want to get out from under it’s shadow without offending the people working on it. The trouble with calling version 20 “Perl 7” is to claim that it supersedes Perl 6. It’s not easy to describe a fork with a linear sequence of numbers.
I like “Perl 2013” as a compromise of sorts: the claim is that it’s this year’s Perl, it says nothing about whether Perl 6 may be next year’s perl.
“Secondly, what it does seem to signify is that the Perl community is going to abandon the stability … ”
I don’t get this. It doesn’t say it to me, and I don’t see why it would say it to anyone else. (Wouldn’t calling it “Perl 7” imply an even more radical break?).
If incrementing the major version number signifies a breaking change, then by using the year as a major version number you essentially say there will be a “breaking” release each year. Yes incrementing to version 7 would signify a breaking release (as minor as the one I am proposing), but we wouldn’t be saying that 8 is coming the very next year.
“Breaking” backcompat in the sense of disabling certain syntax by default but still allowing it to be used if options are set: fantastic? To
no indirectI’d addno bareword::filehandlesandno multidimensional.Wait, isn’t that what
use stricturesdoes, which is used by Moo? hmmmm… :)“Breaking” backcompat in the sense of disabling certain syntax by default but still allowing it to be used if options are set: fantastic! To
no indirectI’d addno bareword::filehandlesandno multidimensional.Wait, isn’t that what
use stricturesdoes, which is used by Moo? hmmmm… :)strictures.pm also enables fatal warnings. There are some warnings I’d never want to be switched on by default, let alone fatal by default.
(I’m thinking mostly of uninitialized, void and once, but also to an extent numeric.)
I can see not wanting some warnings to be fatal, but it’s so rare to need to disable certain warnings entirely (e.g. numeric) that I’d be firmly on the side of keeping them enabled.
Another change one could make in such a release is to do all the things tchrist lists as needed for full unicode and utf8 compliance: http://stackoverflow.com/a/6163129/40468