TimToady but the fact is, Perl 5 is basically in a no-win

situation long term, which we first recognized in

2000

PerlJam TimToady: now you're alienating all the staunch perl

5 supporters :)

TimToady I'm only alienating them "long term"

KyleHa If loving Perl 5 is wrong, I don't want to be right.

8-)

PerlJam Someone mentioned (probably on use.perl somewhere)

that Nicholas tried regular release cycles a while

back. I'd like to know if that's true and if so,

what became of it.

ruoso I don't really think the regular releases is the

issue...

TimToady I love Perl 5 too, but it's stuck (culturally, and

maybe technically) in a legacy trap, and the Perl 6

approach is the only long-term way out of that.

moritz_ ruoso: it's not about *regular*, but about being

able to release when there's something to fix

TimToady Perl 5 is a velociraptor, but we need an

acceloraptor now.

"Clearly, we are right to mock Solaris for making claims that

they will never, ever, *ever* change an interface, not even

one that goes back sixteen years to Solaris 2.3. But it

doesn't follow the opposite point of view, that constant

mutability of kernel interfaces to make sure that things are

always perfect and pure and clean is the right one either."

Here's an interesting dialogue from #perl6 yesterday:There ought to be a corollary to that saying about "Fast, Good and Cheap. -Pick any two". -Something to deal with legacy vs. innovation and revolution vs. evolution. But I suppose the latter is fundamentally a balance between looking backward while moving forward, the threshold of pain you're willing to undergo, and how you attempt to minimize it.I wouldn't pretend to have the experience or wisdom to find the right balance. However, it doesn't appear to be a new problem.C++ went through a period of upheaval not too long ago. There was a nice Dr. Dobb's article on it back in 1997. Well worth reading.Here's a Linux kernel developers thread on the same topic of evolution and change. -A nugget from Theodore Tso: