What’s Wrong with Perl 5
Perl 5 isn’t perfect, though, and some of its flaws are more apparent the closer Perl 6 comes to completion.
Perhaps the biggest imperfection of Perl 5 is its internals. Though much of the design is clever, there are also places of
obsolescence and interdependence, as well as optimizations that no one remembers, but no one can delete without affecting too
many other parts of the system. Refactoring an eleven-plus-year-old software project that runs on seventy-odd platforms and
has to retain backwards compatibility with itself on many levels is daunting, and there are few people qualified to do it.
It’s also exceedingly difficult to recruit new people for such a task.
Backwards compatibility in general hampers Perl 5 in other ways. Even though stability of interface and behavior is good in
many ways, baking in an almost-right idea makes it difficult to sell people on the absolutely right idea later, especially if
it takes years to discover what the true solution really is. For example, the long-deprecated and long-denigrated pseudohash
feature was, partly, a way to improve object orientation. However, the Perl 6 approach (using opaque objects) solves the same
problem without introducing the complexity and performance problems that pseudohashes did.
As another example, it’s much too late to remove formats from Perl 5 without breaking backwards compatibility from Perl 1.
However, using formats requires the use of global variables (or scary trickery), with all of the associated maintainability
and encapsulation problems.
This points to one of the most subtle flaws of Perl 5: its single implementation is its specification. Certainly there is a
growing test suite that explores Perl’s behavior in known situations, but too many of these tests exist to ensure that no one
accidentally breaks an obscure feature of a particular implementation that no one really thought about but someone somewhere
relies on in an important piece of code. You could recreate Perl from its tests–after a fashion.