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.
]]>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.
]]>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?).
]]>no indirect
I’d add no bareword::filehandles
and no multidimensional
.
Wait, isn’t that what use strictures
does, which is used by Moo? hmmmm… :)
no indirect
I’d add no bareword::filehandles
and no multidimensional
.
Wait, isn’t that what use strictures
does, which is used by Moo? hmmmm… :)
(I’m thinking mostly of uninitialized, void and once, but also to an extent numeric.)
]]>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.
]]>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.
]]>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.
]]>See my blog post on the subject for my suggestion as to what to pick.
-- mst, out
]]>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
]]>Thank you.
]]>