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. :)

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.