In 1994, Perl 5 ripped up Perl 4.

In 1997, Perl 6 was announced. At the time, I was excited. (But then, I was still just a youngster.)

Almost 19 years later (and about 22 years after Perl 5.0.0), Perl 6 was released.

Since then, Perl 5 has become far far more deeply established than Perl 4 (or 3, 2, or 1). There's a lot more history to rip apart.

Perhaps Perl 6 should have been called something else, but like it's predecessor, it always was intended to replace it's predecessor. Maybe if Perl 6 development had taken only the few years Larry had thought it would take, things would have been less contentious.

From Perl 5's perspective, it would have been better to not reserve version 6, as Perl 5 has been burdened by still being version 5.x, so has the appearance of being very outdated.

Even what is now Perl 6 would have benefited from not reserving 6. It's been over 28 years since Perl 1 was released. Meanwhile, in 12 years, Fire Fox is at 44, and Chrome is at 47 after only 6 years.

Perhaps if, after the 5 (or even 10) year mark, Perl 6 had been renamed Perl++ or Perl-NG (or similar variant), the taint of obsolescence could have been shaken off by both projects.

Both are worthy languages. I hope both will have at least a decent life.

Good Programmers (like all of us here, right? ;-) know this rule of thumb: You don't tie a feature to a product version number during development! Too many places where I've worked, where the project lead wasn't really a Good Programmer, they used a branching scheme which declared that we shall branch for each release at the beginning of development for that release. That's fine when a "release" is one or two sprints long; but longer than that, and you inevitably run into this same situation: Feature X was supposed to go into Release V, but now we have to slip it to Release W... and now our branch is all whacked up.

For @larry to think that "main-line perl development can't possibly go so far as to need a new major version number before this new successor language is ready for release" reminds me an awful lot of the folly of "No one will ever need more than 640k" and such like as.

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

I find this obsession with version numbers—which good programmers know are nearly arbitrary—incredibly strange. I think of the years I refused to let them upgrade my box to Vista at work. How today I'd rather be on Server 2000 than X, I mean 10, of course.

Larry has paid–rather indirectly and with lots of help, but still–my immodest salary for years now. That this thread is devolving into offshoots "Fuck Larry for screwing Perl5," really, really sucks.

Reputation: 1 (+9 -8)

So sad...deliberately...rip it apart. His stubborn insistence ..Perl in all its forms is done for. Condemned, by the deliberate and malicious-aforethought, to a slow, inexorable decline Perhaps the saddest thing in life is living to witness the genius of youth become the twisted bitterness of old age.

That this ^^^^ hateful, ignorant, anonymous, pusillanimous wagging has a positive reputation is more of an embarrassment to Perl than a 50 year late "version" bump ever could be.

While I don't, the project managers do tie features to specific versions - based on customer requirements. And, at least in the industry I work in, the major version numbers are tied to the project phases. Ideally, we have exactly 5 releases: 1.0.0 (simulation release) through 5.0.0 (production release). More often, we make minor releases as the customer requirements are "refined", and fix releases resulting from "contact with the real world"

FYI, when a customer of ours plans a new product - or new version of a product - they set the schedule. Then they write version 1.0.0 of their requirements and issue a "Request for Quote" (RFQ) to potential suppliers, including the schedule and version 1.0.0 requirements. Then, our project managers review the requirements, get estimates from product development (my division) and make a bid recommendation to higher level management, who decide whether to bid and the actual pricing. If the customer accepts our bid, the various product development managers are directed to assign teams to design and implement a control module based on the "core subset" of the version 1.x requirements for delivery by the Phase 1 due date. (I say 1.x because the customer inevitably continues to "refine" their requirements after the RFQ package is sent out.) Once my team (software) releases 1.0.0 to validation, we start on Phase 2 software.