Review Synopsis: Suffers for overcomplexity ... All-in-all the book suffers from "over-complexity for the sake of over-complexity" approach to Perl ... Aside from overcomplexity, another problem with the book is that it presents Perl as "one-dimensional" language ... any book that presents Perl only on level 3 (which is the case with this book) without mentioning of possibility of using Perl on level 1 and 2, suffers from overcomplexity

-- likbez in Modern Perl 4th Edition

all those artificial examples of "complexity aficionados" advertising those features in their books ... just use a more simple subset avoiding 'extra" features with "extra" complexity

Your attitude ... is wrong and IMHO is the attitude of a "complexity junkie."

-- likbez in Re^2: Modern Perl 4th Edition

I suspect that chromatic is a "complexity junkie" ... the problem remains: inability to reduce complexity of the language, only add to it

-- likbez in Re^2: Perl archeology: Need help in refactoring of old Perl code that does not use strict (hurry up and wait)

And that tells you something about Perl complexity ... This "design decision" ... adds unnecessary complexity

-- likbez in Re^2: Strange behaviour of tr function in case the set1 is supplied by a variable and Re^4: Strange behaviour of tr function in case the set1 is supplied by a variable

I think I'm seeing a pattern here. :)

As a counterpoint, let's examine some quotes from chromatic's excellent Modern Perl book (from the "Advanced OO Perl" and "Style and Efficacy" sections):

• Embrace simplicity.
• If everything else is equal, a simpler program is easier to maintain than a complex program.
• Simplicity means knowing what's most important and doing just that. Sometimes you need powerful, robust code. Sometimes you need a one-liner.
• Simplicity means building only what you need.
• Simple code can use advanced features.
• Simple code can use CPAN modules, and many of them.
• Simple code may require work to understand.
• Yet simple code solves problems effectively, without unnecessary work.
• Decomposing complex classes into smaller, focused entities improves encapsulation and reduces the possibility that any one class or role does too much. Smaller, simpler, and better encapsulated entities are easier to understand, test, and maintain.
• Avoid unnecessary cleverness. Some problems require clever solutions. When this happens, encapsulate this code behind a simple interface and document your cleverness.
• Simple code is no excuse to avoid error checking or modularity or validation or security.

Sounds like chromatic is a "simplicity junkie" to me. :)