| So let's say I decide to put 30 developers and QA guys into writing Perl 5 code for the next year. That's an investment on the order of $6-8 million dollars. 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.