Aside from overcomplexity, another problem with the book is that it presents Perl as "one-dimensional" language.

This is a bizarre comment, to my mind. The "Expressivity" section of the first chapter explains that Perl is designed to be used in the same sort of fashion that you laid out here.

I think your division of "multidimensional Perl" is misguided too. For example:

Basic Perl 5 -- Perl 5 with modules and references, but without fancy staff (like closures, OO, exceptions). This probably the mostly widely used subset.

... and:

Many organizations prohibit installation of SPAN modules for security reasons. In such cases you need to deal with modules included in the distribution, or jump through the hoops to get permission for "non-core" modules. Also quality of modules on CPAN varies greatly, many are unmaintained for years. Blank recommendation to use CPAN is a dangerous proposition.

If I would have taken this advice when I wrote this book, I wouldn't have covered something like DBI for two reasons:

• It's a CPAN module
• It has an OO interface

Similarly, eliding mention of closures would mean there's no good way to explain grep, sort, or map or even lexical scope, which would also be an untenable position for a book attempting to explain how the language works.

If you want a book that ignores the existence of the CPAN and elides lexical variables and won't teach you how to use a CSV module or DBI or anything that uses dynamic dispatch -- itself a 23 year old feature in Perl -- then this isn't the book for you.

Instead, I wanted to write a book that explained the design of the language so that people could use it effectively, taking full advantage of the CPAN, and knowing enough that the copious documentation makes sense without needing a couple of semesters of computer science. After all, once you understand how to look things up in perldoc and what perlfunc means by "lvalue" or "circumfix" or "arity", there's no value in me recapitulating the explanation of index or tr.