However, most people who want the lawn cleared out are really interested in re-modeling the house, not sitting in the back room.
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 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.
]]>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
]]>Thank you.
]]>say "2 + 2 = @{[2 + 2]}"; # "2 + 2 = 4"
That has worked in perl5 for quite a while—I think the newest feature used there is "say".
]]>@{[ ]}
are that it looks quite clunky, it's inefficient at runtime (it builds and dereferences an arrayref), it evaluates its contents in list context, and it gets really confusing if you need (nested) quotes in the interpolated part.]]>