TimToady but the fact is, Perl 5 is basically in a no-win
situation long term, which we first recognized in
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.
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
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
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:
"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."