the problem he has with Perl OOP is that he doesn't trust that other programmers will do it right. His point is that Perl's permissiveness makes it too easy for less-than-expert programmers to weaken the "available software"

I think this problem area is - at least tangentially - adressed by Larry Wall in his "Apocalypse 12" for Perl6,

<quote>
Some of the Problems with Perl 5 OO
A little too orthogonal
It has often been claimed that Perl 5 OO was "bolted on", but that's inaccurate. It was "bolted through", at right angles to all other reference types, such that any reference could be blessed into being an object. That's way cool, but it's often a little too cool.
...etc.<unquote>

The "orthogonality" (or TMTOWTDIbility) of Perl is seldom a problem in smaller programming shops with a highly qualified & focused development team dealing in relatively small dedicated systems.

It can easily develop into a problem (i imagine - i have no practical experience with Perl here) in an enterprise development scenario with a big and complex bulk of legacy code and a "normal distribution" of programming skills. In this scenario good OOP language and business component frameworks (Java, C#) have proven to be a big boost for productivity & quality when "programming in the large".

In many ways Perl5 is like C in that it gives you "enough rope to shoot yourself in the foot" (as Stroustrup has once put it), and that you'll thus have to setup some company standards for coding, documentation etc. in any large it-shop so ensure smooth maintenance and cross human portability.

From what i've seen of Perl6, the OO support will be integrated into the language in a much cleaner and "best of practice" way, which should help position Perl as a better candidate for "programming in the large".

===========================================================
As the eternal tranquility of Truth reveals itself to us, this very place is the Land of Lotuses
-- Hakuin Ekaku Zenji