Who Cares What Version Number Perl Is?

There's a lively discussion going on over at one of Ovid's post, "Perl7".  

I sorta feel like we are not getting the problem at all. I don't think what version is associated with Perl is that important, most people I ask (outside the Perl community) don't even know of the Perl6 project anymore. The CTO and CEO of my last company didn't even know about the controversy or that the project even existed.  My last boss (at my previous company) had not heard of it either.  Its no longer the branding problem we think it is.

I do think for better or worse the delay around Perl6 and the lack of our community's ability to make it a relevant project did hurt us for a while, but I no longer think so.  Based on my admittedly anecdotal experience if we did a poll asking people about Perl6 I'd bet they'd be confused for the most part. So I think the damage there is done but mostly over and gone. Even Duke Nukem Forever shipped a crappy version and the company that owns the title is free to do something better next time, if they want.

When I talk to recruiters and CTOs and Directors, or to venture capitalists and related investors they have heard of Perl.  Perl, period.  Version 5 to 6 is not particularly relevant. Changing the version number is not going to impact how people outside our community see Perl. Here's what I hear and I speak to a lot of people:

Recruiters: "I have a hard time filling Perl jobs". (and we can't just say, "good programmers are hard to find", we've been saying that for 10+ years. Filling Perl jobs is a special category of HARD for recruiters.)

CTO, D-level engineering or software directors: "I have a hard time filling open Perl positions, and I hear NOTHING GOOD about Perl from my peers.  I have no reason to risk my career going to bat for Perl, even if our company is making money using it." There's a certain amount of self fulfilling prophecy here, and honestly I have often felt I had a boss coming from outside the community that was looking for some sort of rational excuse to argue against Perl, but this is what I hear.

Younger programmers looking to get started:  "Perl, WTF?  People still use that?  Oh, you tell me recruiters have more jobs then they can fill, cool, where's all the great docs and tutorials so I can learn how to become a PerlFu master and get one?"

Peers around my own age in industry, "Perl is ok I guess but there's a lot of better options for solving the kinds of problems we have in 2010+.  Glad you still have a job though :)"

Now a lot of ^^ is bias, but there is some rationed basis for it, everything from hiring issues to documentation, to how well Perl is suited for the kinds of jobs we have today.  Its not totally BS.  And a lot of the pros that Perl has, like CPAN and the worldwide CPAN testers system, well that is cool, but similar systems in other languages are not too bad, so we can no longer claim its a killer application for us.  Most languages come with a standard library that does enough as to render half of what I use CPAN for unnecessary, for example.  And online services like Github and integration with Travis continous testing meet a lot of what CPAN and distributed testing acheives for us.  Yes, I know. Its not the same.  Its not as good.  But it crosses the line of just good enough for people that they'd not feel any upside to what Perl does better, given the fact they would have to use Perl to get it!

To me, that is our community big problem.  AFAIK the only valid reason to move version numbers so dramatically is if we are breaking some backward compatibility.   So I really see very little point in thinking rebranding the Perl name is going to help us.  Maybe calling it version 18 next time around might make some sense, since it seems like we will just continue to evolve Perl5, so lets do that if it will get people to stop having this argument every quarter or so, and then we can start to concentrate on our real problems.  Its time to stop mumbling about Perl6 and realize we own Perl5 and its destiny.

 

 

Comments

[Matthew Wilson]

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

[john]

Matthew,

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

[john]

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...