Anybody wanting to advance perl 5 seriously, should consider starting from scratch!

Its called Perl 6.

Unfortunately in relative terms, that accounts for mostly nothing. 99% of the complexity of the perl interpreter/compiler/runtime is due to its initial design.

That's why you reduce & refactor.

30 something years ago I was contracted by IBM to work a maintenance gig on DB2. It was at that point written in COBOL of which I had minimal experience. I did a 4 week course on it at college.

I (typically) went into the APAR database and picked the longest outstanding bugs to tackle. One example was a sev.4 that had been outstanding for 4 years. I spent 3 days trying to understand the bug report in the context of the code; and two more badgering a user to reproduce the problem.

Once I understood the problem I tracked the bug to a 2500 line procedure that, upon inspection, although I understood what it was meant to do, I couldn't, from reading the code, work out how it did it!

So, I threw away the entire body of the procedure, retaining only the inputs and outputs and set about rewriting it to perform the task it was documented as performing. The result was the reduction of a 783 (those who know binary will understand why the figure sticks in my brain), chunk of code to around 20 lines.

1. It fixed the problem.
2. It functioned correctly. Ie. It passed all existing tests plus a bunch I added.
3. It was rejected.

   I could not identify the specific line or lines of code that cured the APAR.

It was the only contract I arranged to leave early -- I bought my way out of it.

Two conclusions:

1. Set-in-stone rules and procedures are the single biggest barrier to progress.

   p5p has lots of them.

2. Any piece of code greater than 20 lines can be improved; especially if freed of the constraints of history.

   Some of Perl's functions are 1000s of lines long.

You may be right -- you usually are -- but, given sufficient will, I'd be prepared to expend some time to trying to prove you wrong.

C'est la vie.