« | Main | Help With My AnyEvent + Plack Tutorial »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Matthew Wilson

*You* don't own Perl ... but it does have an owner, including its name.



Interesting, but not sure what you mean... I don't think I claim to own Perl, although given I've spent nearly 20 years using it, devoted countless hours toward advocating it, writing open source modules on CPAN and helping out people on IRC I kinda feel like I do have some stake in the matter :) But please, let me know what's on your mind. --John

Matthew Wilson

I was reacting to your last sentence "...we own Perl5 and its destiny" and noting it's technically incorrect, especially with "we" being so vague. My point is that I suspect it would take significantly more than just general consensus of p5p, namely, convincing TimToady it's a good idea, to get a significant name change (including "version number") to occur.

Olof Stockhaus

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 to break backwards compatibility so we need to find a way to step the major version to get rid of the mental block.

Olof Stockhaus

Damn, it should have been against breaking backwards compatibility


Regarding breaking compatibility, I guess in my mind given where Perl5 actually is, I can see the desire to break so old features that we don't use anymore, stuff like that. But I just don't see that it is possible for us to break something big enough to warrant calling this Perl7 or something like that. From what I can tell such a platform would have very low to non acceptance by companies that currently use Perl, but that is just my experience and I would love to hear from others on the matter.

Ask your boss if Perl7 came out next year and was unlike to run most of your current Perl based applications, would you transition to it?

My guess here is that a version of Perl that busted more than 5% existing applications would just not fly. I couldn't even convince people at my last few jobs to move up from Perl5 version 8, let alone some new version of Perl that would require massive retesting and re-review of the entire application. I just don't see it happening.

Heiko Jansen

"My guess here is that a version of Perl that busted more than 5% existing applications would just not fly. I couldn't even convince people at my last few jobs to move up from Perl5 version 8"

IMHO, that probably nails down the reason why we _need_ to break compatibility in a controlled way...

Those who have old established code bases don´t care much for modern perl. But the user base is slowly eroding because new projects do not use Perl anymore and because we do not attract fresh blood from outside the established community.

So a) lets declare a more-or-less current release to be a long term support release which will receive security and bug fixes for at least 5 years.

And b) break backwards compatibility wherever it´s needed to allow for cool features, e.g remove the barriers Stevan et. al. hit when trying to implement the in-core MOP; enable maximum unicode support by default; enable strict etc.

Making it mandatory for newcomers and/or new projects to jump through various hoops to get the best out of Perl really isn´t helpful. Just look at http://www.perl.com/pub/2012/04/perlunicook-standard-preamble.html or try to explain why there´s both Moo and Moose (and the differences) and why you don´t get all that by default.
And no, improving the documentation is no alternative.
Changing the version number itself is only an outward sign but it won´t do us much good just by itself. I even think it would be harmful if we changed the version number without being willing to simultaneously make much deeper cuts.

If we don´t dare to modernize Perl, then - I fear - Stevan is right and Perl 5 is a dead end...

The comments to this entry are closed.