Perl.com: Report on the Perl 6 Announcement
Jul 31, 2000, 23:08 (0 Talkback[s])
(Other stories by Mark-Jason Dominus)
Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers
"There are two big problems with Perl 5."
"First, the internals are extremely convoluted. It's hard to
hack on Perl's internals. There's a lot of accumulated cruft, and
Perl 5 has reached that stage of maturity in which it's difficult
to make a change or fix a bug without introducing some new bug. The
excellent test suite prevents the new bugs from getting into the
release, of course, but it also prevents the new feature from
getting into the release."
"The addition of threads, the compiler, bytecode generation, and
Unicode support is still incomplete, because none of those things
were designed into Perl 5; they are all being bolted on afterwards,
and it shows."
"The other big problem is thirteen years of backward
compatibility history. The porters might like to rationalize the
syntax a little, or clean up Perl's semantics, but that might break
old code, and Perl is committed to not breaking old code. We can't
add a new built-in function because it might break old code. It's
extremely difficult to remove even the most bizarre and little-used
old features, because it might break old code. Every few months,
someone suggests replacing Perl's garbage collector with a more
modern one, but there are always objections from people who have
written code that assumes that the garbage collector will always be
reference-count based and that it can control when objects will be
"Technically, there's not very much "wiggle room" in the
source code, because the internals are so convoluted and difficult.
And there's not much "wiggle room" in the language itself, because
of the need to support ten-year-old Perl 2 code."