Perl 7
At the risk of starting a massive flame war, I have only one question: what are the pros and cons of releasing Perl 5.20.0 as Perl 7.0.0?
57 Comments
About Ovid
Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you.
And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/
As lot of people already said, the main problem was using 'Perl 6' for a different language. I think going 'Perl 7' for a 'Perl 5' improvement will not work as expected.
My point of view? We have two languages, one named 'Perl 5' and other named 'Perl 6'. Perl 6 has a lot of interpreters and compilers, each with their own version. For 'Perl 5', we have only one interpreter (or, ok, mostly one interpreter), and that interpreter is on version 20!
Therefore, I do not vote for Perl 5.20.0 being called Perl 7.0.0. But if anybody insists on changing, I would vote for Perl 5, version 20.0.
If Moe project success, I will vote for Perl Moe = Perl 7
The answer is in the question: "the risk of starting a massive flame war".
I'm also in favour of Perl 5, version 20.0. There's precedent for this - Sun dropped the "2." from Solaris version numbers, releasing Solaris 7 and 8 instead of 2.7 and 2.8. They repeated the trick with Java, where 1.4 was followed by 5, 6 and 7.
I personally think a Perl 7 in the roadmap would be a good idea, but not if it would be 5.20 in disguise.
In my opinion a few major things needs to be added/changed to motivate a new Perl major version and at least some break backwards compability:
A mop in core perl with Stevan Little's attempts as a blueprint (blessed references still supported though)
Function signatures instead of prototypes
A real language specification
Optionally these things would be good to have too, but they can be added in later releases if currently conflicting functionality is dropped or moved into optional modules.
Optional typing
Lightweight threads
Simplified smart match operator
Multi-method support (same function with different signatures)
Class-based exceptions
In essence I think we require major new functionality and a break in backwards compatibility at this stage to go for Perl 7
While I understand the idea of going for Perl 5 ver 20.0, 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!
I agree with Joel Berger, I vote for Perl 7, and Perl 8 not too long after.
I don't see why Perl 5 should continue suffering from Perl 6 diversion anymore. One of the 2 languages should have his name changed from Perl to something else. And I don't think Perl 5 should change. Perl 6 is the different language, right ? let's call it Camelia, like discussed somewhere else, and let Perl 5 catch up on the version numbers.
Unlike Olof, I don't think Perl 7 should have a lot of improvements. I should be like 5.20, maybe with some useful modules shipped by default ( definitely some Moo* stuff ), so you get more features by default, but you still decide to use them.
To give some background:
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.
Now many of you see the glaring flaw in the above: version numbers mean nothing. Perl went from version 3 to version 4 mostly to help out a book and the Linux kernel went from 2.6 to 3.0 to celebrate an anniversary. So while version numbers may not have an intrinsic meaning, they have a huge impact on perception. With so many other languages have major version upgrades and Perl "languishing" at Perl 5 for two decades, the perception is that it's stagnant. And remember, the Perl 6 project was conceived when Perl 5 was only 7 years old. (Even Python has gone from 2 to 3 and with Django getting Python 3 support, that split is going to heal).
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.
Since Perl 6 appears to be staying named Perl 6, why not skip the entire debate and rename Perl 5 to Perl 7? Perl 6 will likely get renamed PDQ, there will be huge amounts of press over this (much of it pretty ugly) and we can finally put to rest the silly "no major release" argument.
That, or we skip version numbers all together and call the next major release "Perl Leapfrog" or something like that and go from there.
Or, given that P5P seems pretty committed to yearly releases, Perl 2013, Perl 2014, etc.
That way, the Perl 6 effort can lay claim to all version numbers between 6 and 2012.
Toby, that is a very intriguing idea, though there is a certain amount of implicit commitment. I wonder how the business community would react.
Yes, Many linux distributions have switched to year related version naming (Mandriva, Gentoo come to mind).
Perl 2013.1 for first (or second, depending if we start at 0) quarterly release. Sounds nice to me.
This superb "background" information should be in the main blog post instead of the comments ;-)
It quite made me understanding what your point is.
I like Damien's idea of "Perl 2013.[1,2,3,4]", or maybe "2013.". I mocked Sun for changing their numbering scheme back in the day, but the pattern did end up working well for them.
Probably don't want to wait on developing a long feature list, either. That way leads to heartache as new feature X is found to be incompatible with new feature Y or breaks significant existing feature C, and the release gets pushed out further until everybody's pet feature / bug is taken care of. This usually never finishes, because "everybody" is a lot of people.
Just shuffle the versions sooner rather than later and put the shiny new features in as they're developed.
Bah. That was supposed to be "2013.month-name" - me and my love of pointy braces.
You could also do what Emacs did and drop the major version number. Perl 20, anyone?
Brett
I think people still haven't stopped ridiculing SUN for releasing Solaris 7 as the successor to Solaris 2.6.
In the end, it doesn't matter at all how you label a Perl release. The IT world consists mainly of people having uninformed opinions -- lots of people will ridicule Perl regardless of its version number, just as most Perl people will ridicule PHP, Python, Java or some other popular language regardless of their version numbers. People who know enough about Perl to have an informed opinion will not be fooled by calling the next release Perl 7, and those who aren't informed will not suddenly gain knowledge after a name change.
Renamming Perl 5.20 to Perl 7 would be a signal to the world outside the Perl community that Perl 6 is a failed project. A bit like PHP 6.
But Perl 6 is not a failed project. Jonathan Worthington is advancing quickly in his port of NQP to the JVM, which is the first step in porting Rakudo to the JVM. Once Rakudo will run on a serious VM it will get much more interest, from users and from contributors.
So Perl 7 is just non-sense.
If the matter is just marketing, Perl 5 version 20 would be fine for me.
Why not leave the '20' out of '2013' and make it Perl 13 etc ?
The year as version number is actually brilliant. It would make shaming people much easier for using outdated perls: “You are using 5.8. Seriously?” vs. “That stuff is a decade old.”.
Using years also doesn't have to mean that one big release would have to happen each year. Think of it as “the state of the art”, much like Modern::Perl requires an explicit year.
Jumping to “perl 7” would just create infinite confusion, which wouldn't do either incarnation of Perl any good. Dropping the leading digit would fit the way I already think about the releases, but it would feel like the version-whoring certain browser vendors like.
Olivier: I agree that "Perl 7" is very problematic, but "Perl 5 version 20" gets back to the core of the issue: people will see Perl 5 as dying and Perl 6 as the logical successor instead of a different language. We would gain nothing.
Perl 2013.1, on the other hand, seems to be a very reasonable compromise. The aesthetics aren't important; breaking people out of conventional thinking patterns is.
Every once in a while, like when meeting a non-Perl programmer in person, or hearing another "Perl is Dead!" screed in the echo chamber (they are as rare outside the echo chamber as "Sun is hot!" rants, and for the same reason - nobody cares about restating common wisdom), a Perl person will wonder "why the heck don't we get granddad to move that big pile of junk he's been tinkering with off our front lawn, so the neighbors will stop thinking our house is an abandoned shack in the garbage dump?"
"I mean sure, it gives granddad something to do, and maybe once in a while he'll get a bright kid to wander in and get excited. But really, once those kids mess around a bit with some loose gears, they get this compulsion to take the whole thing apart again, then gradually lose interest and wander off, leaving even more of a mess."
"And granddad won't let us clear it all up, says it's his baby. Won't feel right taking it away from him, after all, he put up this house and he'll make all kinds of fuss."
So the Perl person throws a fit, and his or her brethren say "right on!" or "let's move!" or "let granddad move!" For some reason, numbers keep getting mentioned.
Then we all sigh and go back into the house to do our work. We ignore granddad and his big science project. We follow our neighbors and even talk to them on the street, and everything's fine until we bring up where we live and they go "Someone still lives in that place? I thought it was abandoned".
And we start again with "granddad's blasted science project" and "get him off our lawn".
Until we move.
I want my Perl 666 now.
As a perl 5.8 (yes you read this right) die-hard I must state that I do not share in any way your feeling towards "granddad" and the "excited kids" playing with that "science project".
@dolmen : For me, Perl 6 has not failed at all as being a next generation language. But it's not anymore "the next Perl". It's a different language. So it should not be in the Perl namespace. Or so I humbly think at least :)
Peter: 5.8.7 here, although I've no strong opinions on that. However, most people who want the lawn cleared out are really interested in re-modeling the house, not sitting in the back room.
I like Perl 5, v20 but the name doesn't really matter. We need two interpreters, two development groups. P5P needs to split. One for backwards-compatible Perl 5 and another for modern Perl 5.
I don't think any real user of perl5 wants a "Modern perl5", which will fail to run 90% of the CPAN. Perhaps you want a Moe?
Perl 6 seems like it has quite a bit of responsibility for leading to the 'Perl is dead' mentality. Even if it involves some initial bad press, it's probably best to rename Perl 6 to something else and let the evolving Perl keep its name, not give it to a different language that is Perly.
I think the main trouble with the "perl 7" idea is that the perl-porters aren't interested. Maybe they'd go with the year-as-version idea.
The discussion of the "perl7" idea from back in 2007: http://www.nntp.perl.org/group/perl.perl5.porters/2007/02/msg120481.html
My comments became too long, they now reside here: https://blogs.perl.org/users/joel_berger/2013/02/on-the-version-number-succeeding-perl-5.html
The more I think about it, the more I think using a year-based versioning scheme is a great idea. I was very opposed to it when it first hit mainstream (Windows 95), and I still think Microsoft does a piss-poor job of it (the name is 95% marketing). However, Ubuntu really turned me around on the idea. They're doing software releases based around a calendar and they do their versioning based around the calendar, and CLICK, it makes sense.
I think this would be an excellent change for Perl. One issue I regularly run into is the huge disconnect between Perl versions and their age. Perl 5.6.0 is 13 years old; Perl 5.8.0 is almost 11 years old; Perl 5.10.0 is over 5 years old. People in the Perl community know that Perl 5.6.x is ancient and that 5.8.x is old. But people outside of the Perl community don't see that. They see it all as "Perl".
I'm really liking this idea.
I think there's some real value in the year-based versioning scheme. As you've said, looking at older Perls, it really isn't obvious how old the builds are solely by looking at the version numbers. I know I don't have that info memorized. I think it's a change well worth considering.
Toby++
Next May, Welcome Perl 2013!
Or Perl 2013.0 Or Perl 2013.1 Or Perl 2013.5 (like Ubuntu)
perlhist.pod will be more easy to maintain :)
But, what about the development series?
As I comment in my blog post, I think year-as-version has an bad side-effect: it has the appearance of allowing breaking changes yearly. Whether or not its true, the appearance of losing Perl's legendary stability might be worse than a stagnating version number (which I also don't want to see). https://blogs.perl.org/users/joel_berger/2013/02/on-the-version-number-succeeding-perl-5.html
I suspect Larry would be against the idea. One of the Perl 6 RFCs said something like 'Perl 6 will be the last version of Perl' and Larry's response was along the lines of 'Perl 7 will be the last version of Perl. 6 is a number signifying imperfection, and 7 is a number signifying perfection'.
I hope you nor Larry takes this as a slight, but that is the worst reasoning for version numbers that I can possibly think of. As many people know, the version number of metafont is tending to
eand the version number for TeX is tending topi, but those projects are SPECTACULARLY stable, and not something likely to be repeated for something as complex as Perl.I don't think most people associate the introduction backwards-compatibility breaking changes with the year-based versioning. That sort of baggage is pretty heavily attached to the standard Major.Minor.Patch versioning, but I think it drops out of scope a little with year-based versioning.
As it stands, people who know Perl have grown accustom to a very (some would say overly) strict policy towards maintaining backwards compatibility to an almost extreme degree. I don't think year-based versioning would give the impression of constant compatibility breaking changes, although I do think it would make it easier to introduce those changes and get people to accept them.
With the current versioning, and its traditional Major.Minor.Patch style, many (most?) people familiar with that versioning scheme assume that backwards compatibility will be maintained across Major versions. That means that as long as we're still making releases that are Perl 5.x.y, people will expect that it will never change. I don't think we should start breaking things because we can, but I also don't think we should still be supporting deprecated features from Perl 4.
An option would be for Perl 5 to take odd Major version numbers (Perl 7, Perl 9) and for Perl 6 to take even (Perl 8, Perl 10).
Still seems to me that Perl 6 should have its own name!
Since Perl 6(Camelia) is meant to be somewhat(albeit distantly) related to Perl 5. How about renaming Perl 6 to Vidalia? Let Perl 5 continue on an agreed upon incremental version naming scheme.
No, I don't want Moe. What I want is a Perl 5 interpreter that is compatible with 90% of CPAN but is not afraid to break the other 10% (not to mention the DarkPAN) when it is necessary to improve the language.
To clarify: The mop and the signatures would not have to be there in the first release of the new major version, but the backwards compatibility breaking changes needs to be done by then.
For me, the "mess on the lawn" is not Perl 6 but the deterioriating state of the CPAN. For anyone who isn't a power user living on the bleeding edge, it's challenging to find good modules on the CPAN and distinguish them from things that are broken, have horrible implementations, are bug-ridden, or simply won't compile on newer releases.
I'm not sure yet exactly how to go about solving this though.
I really LOVE LOVE LOVE the version being the year track. That solves it all.
"it has the appearance of allowing breaking changes yearly."
I don't buy that line of argumentation at all.
Personally I don't much care for stupid version number games, but then I don't much care about the details of the version numbers at all, so Ovid can count me as a 'yes, if you must'. My point really was that if Larry says no that's final, and I suspect he will. (But I don't know, obviously.)
However, I think we are missing perhaps the most important advantage of keeping Perl 5: the major version number is only revved when backwards-compatibility is broken in an important way. Perl 5 is still Perl 5 because of the huge effort p5p have put in to maintaining back-compat. That seems like something people ought to care about, to me.
Nothing would change about the way the Perl maintainers announce versions and nothing needs to.
This is purely a "no major version" perception problem that is solved (IMO) by going to a yearly naming scheme of some time like "Perl YYYY.M".
I do not believe at all that going to that scheme gives the perception that the maintainers are suddenly breaking things nor that backwards-compatibility got thrown out the window.
I do believe it gets us around, elegantly, the naming issue.
Nice idea. In this way we can convey the message to the world that Perl is not dead. Either we can go for Perl 7 or can agree on yearly releases (as suggested by Toby).
There's a problem here that I don't see being discussed. "Perl7" or "Perl2013" or "Perl Foo" is a fork, plain and simple. The 5.xx line will not end just because somebody decides to evolve Perl5 into something not quite compatible with what it was. There will still have to bug fixes, which means maintainers, which means itches to scratch and ideas to try. In short order, we will have Perl v5.2x, and Perl6, AND Perl 20xx.
Stevan Little already explained that one of the reasons he decided to build from scratch with Moe is that there's a serious shortage or surgeons qualified to operate on the current Perl5 implementation. And another reason is that this implementation is a terrible candidate for major surgery. Choosing new names or numbers won't change any of that. I say wait until we have something to show the world before we trumpet huge improvements. If Moe produces an architecture and a new slimmer core that we can build both backward-compat modules and great-leap-forward modules on, THEN talk about what to call it.
Perl 6 already has Rakudo with a monthly release cycle with year and month in the name. At the moment we can all work with Rakudo Star 2013.01 and work is being done on 2013.02.
Renaming Perl 5.20 to Perl 7 and skipping Perl 6 is throwing away man-years of work, energy, inspiration. Just talking about it might demotivate everybody in the community of Perl 6 developers.
Many people are not interested at all in Perl 6, even not knowing that enormous efforts are made to make Perl 6 more and more backwards compatible with Perl 5, and giving Perl 6 more features that people are waiting for.
The problems of Perl 5 will not be solved by renaming it Perl 7. Anybody watching Perl will see that it is a trick. We will be mocked. No problem will be solved.
I believe that such action would be a real nail in the coffin. After all the talk of Perl 6 being the language of the future, people see a Perl 7 release, think "Wow lets take a look" and Perl becomes a laughing stock when they all see it's just a patched Perl 5. What's worse this would jeopardise Perl 6, and all that's gone into it. I think a better title would have been "How to wipe Perl out for good with a simple version number change" or more simple "The Perl 7 one liner of death".
Perl 6 is the future, an I firmly believe it'll fix everything. If people are impatient then the solution is to contribute to that project.
So IMHO no, no, no, please no.
As an alternative idea - how about we pick a name rather than getting even further into the numbers game?
See my blog post on the subject for my suggestion as to what to pick.
-- mst, out