Oh fuck off, no one has been confused/concerned about the 5 vs 6 version numbering thing for at least 10 years. 5 is production, 6 is where the crazy geniuses experiment with language features, everyone knows that they're two separate things. Since 5.10 we've had major (sub)versions of 5 every year, consistently. And the better ideas from p6 creep their way back into p5 in the way of modules or features in new versions, so it's hardly for naught. The only real mistake was calling it "6" instead of "Dr. Wall and Conway's chimera language of onion and camel goodness" or something.

Why should I choose to do that? 5 is a moving target, and the island of stability (Perl 6) seems to be just around the corner forever. Except 6 will be an early, unoptimized version of whatever it will eventually become so I won't want to use it till it's well tested in real environments. Okay so I wait another year after 6 comes out, now I have even more legacy code to deal with.

So what are the metrics to port Perl 5 to 6? I have no idea, nobody really does. What does it cost to move 2 million lines of Perl 5 to Perl 6? The syntax is just different enough that I'll have to add another $1-2 million dollars or so into the long-term budget to port my Perl 5 code to Perl 6. I'm aware there are some conversion utilities, but now I have to QA all of the converted code and check for regressions and then fix them when they show up.

Sure I can just write for 5.xx and just stay there forever, but what if 6 does generally come out? Will the development community just shift over to 6 and now I don't get feature improvements and bug fixes? What's the long-term support case look like? I can't exactly contract the "Perl Company" to ensure I have long-term Perl 5 support for the next 5-10 years. So I'm just guessing and praying that what I'm building will have long-term support.

Or I can just tell my team to build in Python or Java or something else, not worry about all this and save $1-2 million in eventual porting and long-term maintenance costs.

There's actual business reasons for this. Every technical decision maker ruminating on Perl has gone through this, and they've decided to not go with Perl for these kinds of reasons. Which is why there are so few jobs requiring Perl, and why nobody bothers to learn it anymore.

Now, you may be swimming in hundreds of millions of dollars of personal wealth and can afford to make the decision to go with Perl, and that's cool. But unless you're willing to offset instability in the platform with personal investments in thousands of companies and development efforts, you can swear at me all you want, it won't change anything until Perl is again a stable platform and is solving people's problems.

To put the woes of Perl 6 in even more perspective. It's taken so long for Perl 6 to happen that Go, a language that didn't even exist when Perl 6 was announced, had a team formed, was announced, was developed with full-tooling and a robust standard library, went through betas, and is now in production use inside of hundreds of companies in less than half the time than it's taken for Perl 6 to get into some kind of alpha stage from announcement.

The idea of 6 as an island of stability and 5 as a moving target is exactly backwards.

And Perl 5 has had fewer breaking changes than any of its popular scripting siblings... Ruby (1.8 -> 1.9 anyone?), Python (oh, yes, let's talk about 2 vs 3, shall we?), or PHP (in which build flags introduce breaking changes, let alone stuff that's come with some 5.x dot release).

> So what are the metrics to port Perl 5 to 6? I have no idea, nobody really does. What does it cost to move 2 million lines of Perl 5 to Perl 6?

It doesn't matter what it'd cost at this point because there's no reason to do it, nor is there any visible time on the horizon at which you'd need to do it. Like the GP said, 5 is production, 6 is where people experiment with language features, and 5 has shown that it has plenty of future through regular stable releases and feature enhancements since 5.10 (released 7 years ago!).

> Every technical decision maker ruminating on Perl has gone through this, and they've decided to not go with Perl for these kinds of reasons.

Every technical decision maker worried about the Perl 5->6 transition over the last few years is someone who didn't actually do the kind of diligence a good technical decision maker should do, and hopefully that's a one-off mistake rather than indicative of the general quality of their judgment.

That's unfair. The current motto of the p6 faithful has become "It's a sister language not intended to replace Perl" over the years, but a lot of things have changed over the years. If and when a usable p6 is released, who knows what the motto will be then?

You brushed over the Python 2 to 3 migration, but at least that one had a coherent strategy. It's not an easy strategy, but there's an end of support date for Python 2. There's a widespread effort to port libraries and frameworks and projects to Python 3.

That hasn't happened yet for Perl. It's not clear if that's ever going to happen for Perl. No one is exactly sure how much of the CPAN p6 will support, if any.

Will people start writing more new code in p6 instead of Perl? Will people port code from one to the other? Will p6 be able to use existing libraries? Will those libraries be usable in the same process?

When will p6 be stable? When will it have documentation? When will it have support, from a community point of view or a vendor or bundling in a supported distribution? When will it have tool support? What is its deprecation policy? What is its support period? Who will use it? What will they use it for? How much training do they need? How much do they charge? How easy is it to hire them?

There are so many unknowns. It's unfair to sweep them under the rug and say "Everyone should know that Perl is Perl and 6 is something else and the latter doesn't matter."

I guess I don't see why that's an important question when:

- there's no horizon on which a complete implementation (or stable target for a spec/test suite, for that matter) is promising to arrive

- 5.x has demonstrated it's a living/growing branch with as much a future as any open source project

- By comparison, for something like Python, the concrete reality of having a plan for changing horses midstream seems to be more painful than just keeping on with Perl 5

Or are those false assumptions?

I don't really expect everyone to keep up with everything about Perl. I'd certainly had no idea 5.10 was even a glimmer in someone's eye for over a year after it had come out because I was busy with front-end work and PHP projects. And I'm responding partly because maybe I've missed something again and this is a learning opportunity.

At the same time, when someone speaks up as the GP did and asserts that technical decision makers have done their homework and picked things like Python or Java by comparison to insulate themselves from the spectre of version shifts and associated porting costs, I think they may have earned themselves a challenge.

That is the problem.

The future of Perl is very, very difficult to predict. 14 years ago, the next major version was announced. It was explained and designed and promoted in public by gathering the community's list of 361 technical flaws.

P6 is now older than Perl was when P6 was announced and no one can tell when or if P6 will replace Perl. That includes developers as well as users and technical decision makers. If you start a new project in Perl today, how long will it be supported? Will you be able to hire or train enough developers? Will you be able to retain them? Will P6 ever replace Perl?

Python has its difficulties with the gradual adoption of Python 3, but at least there's a consistent and coherent story about community expectations. Perl doesn't have that, and that, to me, as a technical decision maker, is a huge risk.

Iirc, he has trolled in Perl discussions before.

For a multi-million dollar development with more than 6 developers, code is the least of your worries.

That's b/c the C++ standard library (or its implementation among various compilers) was terrible 13 years ago when Qt 3 was released. Some say it still is.