I mean no discourtesy to TheDamian. Many of his modules have been handed off to others, whilst many others are deemed unsupportable.

And without in any way in inpuning any particular current maintainer, including Alberto, TheDamian is a hard act to follow. Especially TheDamian of the era when he wrote most of his most sophisticated modules. I have my doubts, even if he was still active in the P5 arena, whether he would be able to maintain the depth and breadth of knowledge it took to make many of these modules work in the first place, in the light of the ceaselessly moving target of both the state of the internals and the multiple hands on the tiller pulling it in ever new directions. As trends and fads change, so the ability of even the most talented individuals to keep up is limited, especially as the demands and rhythms of real life take hold.

It's also an extraordinarily thankless task to maintain the works of an extraordinary author. Like asking a session musician to maintain the works of Beethoven; or a house painter to touch up a Cezanne.

You're quite right, on all counts.

Interestingly, in Perl Best Practices, Damian quotes a very relevant aphorism from Brian Kernighan: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

Advice we should all live by. :-)

Hm. That's another of those sage pieces of advice that gets quoted far too often, and nearly always out of a correct context.

Debugging and maintenance are quite different things. Although the latter can involve some of the former, it first starts by breaking working code in order to adapt it to new requirements. That is, you do not normally enter maintenance mode until a "working state" has been achieved.

This becomes particularly significant when the working state is achieved at or close to the limits of what is possible--as with many of TheDamian's modules. They rely for the possibility of their operation on being closely coupled to the (internal) features and even quirks of the Perl. As such, they become susceptible not only to breakage through internals changes, but also to the 'fixing' of quirks. More significantly, they require deep understanding of those internals--and how they change over time--for their initial possibility and their continued operation. Unless the maintenance programmer fully grasps their modes of operation in their original form; plus all the internal changes and how they affect the operation; they are hard pressed to be able to keep them working as the internals evolve over time.

There is also a difference between 'clever' for it's own sake; and 'clever' of necessity. When pushing the boundaries of possibility, it is often necessary to clever. The alternative is to achieve nothing.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW It is as I've been saying!(Audio until 20090817)