Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Modern Perl 4th Edition

by likbez (Acolyte)
on Nov 17, 2017 at 18:42 UTC ( #1203697=bookreview: print w/replies, xml ) Need Help??
Order Modern Perl 4th Edition

Item Description: A good refernce book. Kudos for chromatic for making it availble freely

Review Synopsis: Suffers for overcomplexity

It's a usable reference (it's intended purpose) that covered all the most recent Perl enhancements and new features up to Perl 5.14 or even 5.22. Might also be beneficial to any seasoned Perl programmer who wish to update his knowledge of latest and greatest language features.

For those purposes most material that is covered is covered well, with the distinct approach that "newer is better". Kudos to you for making it available for free, as Simon Cozen's book now is somewhat outdated (2000). I actually like his approach better, although his examples look overcomplicated.

The problems start if you use this book to learn programming in Perl. It's bad book for this purpose. Clearly it is a "language junkie" written book. It does not distinguish between important and superficial/esoteric things in the language. Everything is, kind of, "treated equally" independent of complexity and the level of abstraction that a particular feature introduces: Ohh we have this great feature. Here it is ;-) This "Schwartzian" approach is a very bad idea for beginners, even if they know some other language really well. And not so good for accomplished programmers either, although they suffer less from it and can benefit from delving into most recent esoteric staff (sometimes :-). All-in-all the book suffers from "over-complexity for the sake of over-complexity" approach to Perl.

I also noticed two rather obvious problems with the book: (1) Looks like it does not cover Perl debugger. At all, as if it does not exists. (2) It does not contains adequate coverage of built-in functions such as index (mentioned only in passing in index), substr (not in the index), tr, to name a few.

Also regex searching on long strings with newlines is an important topic (modifiers s and m) for modern Perl usage, coverage of which can be improved and expanded.

As for advocacy of Moose, this was a very questionable decision on the part of the book author. 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.

Perl 5 now is the language that most people use in rather limited subsets, the idea which is missing from the book. Nobody probably knows or uses the "full Perl language". It is the classic situation with blind men and elephant. It is also true about other languages such as Python and Ruby.

Even using a very limited subset of Perl can be somewhat problematic as there are way too many special cases and gotchas. This is clearly non-orthogonal language and this has its strong and weak sides. How to avoid problem that arise from this is topic that is very important for Perl programmers. Aside from advocating to use scrit and warning the other relevant methods, such as switching to use of IDE are also missing from the book. for example, Padre or Pycharm can be used (Pycharm does support Perl, although this is not advertised). Any language is no just the language, but is the whole ecosystem which includes among other thing the debugger and IDE.

Please note that it does not make sense to adopt "Pythonista" approach to the same domain either, as it stands father from the spirit of "Classic Unix" than Perl to say nothing about related unhealthy infatuation with OO that Python promotes. OO actually is a pretty limited paradigm of programming suitable only in few (but important) areas; historically it came from languages oriented on simulation (Simula67), which is an important, but not all-encompassing domain; later it acquired some features of "compiler-complier" approach.

But other approaches also exist. For example, coroutines can also can be viewed as a software development paradigm for certain type of programs (that allows structuring the problem into multiple semi-independent passes with intermediate representation produced in each) and I am not sure that it is not better for this particular domain. Success on Unix pipes speaks volumes about power of this approach.

Aside from overcomplexity, another problem with the book is that it presents Perl as "one-dimensional" language. In reality Perl exists at least on three distinct levels:

1. Minimal Perl. Perl 4 subset of Perl 5 -- which surprisingly is adequate for many tasks; especially in Unix system administration area. This is the level of the language typically used in one-liners, small Unix-maintenance scripts, and such. This is s kind of "Perl as better bash, AWK and sed." level.

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

3. Enhanced Perl 5 -- Perl feature level typical for people who speak at Perl conferences. That include polymorphism, inheritance and other complex staff that is useful for example for writing interactive program with complex GUI and such.

I think that 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. I think a proper book on Perl should be like an onion with at least three layers of coverage outlined above. Of course, such a book is very difficult to write.

Replies are listed 'Best First'.
Re: Modern Perl 4th Edition
by eyepopslikeamosquito (Chancellor) on Nov 18, 2017 at 00:41 UTC

    Though I strongly disagree with pretty much everything you've written, I doubt I can change your opinions. Based on your (strong) opinions, instead of Modern Perl, I suggest you try these two books instead:

    In case it helps, chromatic gave some background on the philosophy behind his Modern Perl book in this thread:

    Modern Perl assumes you're already decent at programming, so it elides some basic stuff in favor of explaining how Perl works from philosophy to programming in the large. Learning Perl assumes you've never programmed before, so it spends more time on the basics, covers less of the language, and doesn't explore the philosophy of Perl in as much detail.

    See also: List of PM nodes discussing Perl books

      This is exactly what I would have written--I had Maher's book in mind in particular--had I not been too irritated to reply to the OP.

Re: Modern Perl 4th Edition
by chromatic (Archbishop) on Nov 18, 2017 at 07:44 UTC
    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.

      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.
      The road to hell is paved with good intentions.

      There is such thing as the "level of abstraction." The ability to operate on various levels of abstraction and switch them at will is the talent closely associated with the software architect talent. If it is absent, the guy is just useless as a software architect and probably is a bad programmer too. You tried to remove all, even existing, links to the lower levels of abstraction (for example, by choosing to cover Moose and avoiding old school "bolted on" Perl OO mechanisms). IMHO that creates the "house of cards" situation. I think that's a dangerous strategy.

      My position is that a competent Perl programmer needs to know and strive to learn some C, and should have some genuine interest (at least on the superficial level) on how various Perl constructs are mapped in memory, how Perl interpreter symbol tables are organized and how they are linked to the notion of namespaces, and how garbage collection works. IMHO it is challenging to learn Perl to sufficient depth staying on "pure Perl" level. As a minimum, the person should learn well Perl debugger in addition to the language. From this point of view features that are not well represented in Perl debugger should be avoided. So complete novices, who try to learn Perl "without needing a couple of semesters of computer science," probably should use Minimal Perl book by Tim Maher and stay away from yours.

      So I see a problem with a high level "pure Perl" approach, which is what your book is about. There is little coverage of "Perl ecosystem" outside CPAN in your book. Lip service is not enough. There is no chapter about Perl debugger. There is no chapter about Perl ability to call C.

      And that's why I think coverage of the "classic" text manipulation functions is important. They represent a lower level of abstraction than regex (and historically they are older than regex; I think substr, index and tr were first defined in PL/1 around 1964; regex history started around 1968.). So coverage of both means adherence to Perl slogan "There's more than one way to do it" and coverage of only one is a betrayal of this slogan. As simple as that.

      I think that various levels of abstraction need to coexist in the same language. And that's why I like Perl. But "my Perl" is not the language I have found in your book. Yours is a different Perl.

      While the higher level of abstraction represents the progress of the language, that does not obviate the need for the features that exist on the lower level of abstraction. You need to give people a choice, not to corral them into the highest level of abstraction available.

      In this sense, the ability to use small C fragments in Perl (see the discussion at XS Library - Embedding C code in Perl), the good understanding of classing string functions as an alternative to regex (Perl, after all, is a great text processing language), etc., are so important and, as such, represent Perl advantages. Classic Perl slogan "There's more than one way to do it" should be interpreted as "There's more than one way to do it on different levels of abstractions." IMHO.

      For example, Moose does provide the higher level of abstraction of OO than the "old school" Perl5 "bolted on" OO solution. But the question arises whether the advantages justify the cost and learning curve, as well as how much of it is the pure "syntax sugar" and how much is the "meat." The fact that "Moose is more smooth" does not make it inherently superior. All depends on your needs as a programmer.

      The ability to see the OO "Kitchen," even if it is dirty, is also a valuable feature. Especially for students. That's a positive feature of "old school" Perl OO in comparison with Ruby and Python: it does provide access to lower levels of abstraction for OO. People are smart enough to choose what is best for them. But that means that it might be beneficial to cover both in a reference book. I, for example, will not approach Moose, unless I need to maintain somebody else code that uses it.

      While creating the higher level of abstraction is the name of the game (and that's why Perl became popular), a "reckless" drive to higher levels of questionable abstractions can be self-defeating. That's what I mean by my "house of cards" analogy.

      Many people resent being in the situation when they need to catch a black cat in a dark room (when internals of a complex feature are completely hidden), all those artificial examples of "complexity aficionados" advertising those features in their books notwithstanding. And in such cases, programmers either abandon the language and use a lower level one (for example descending from Python to Java) or just use a more simple subset avoiding 'extra" features with "extra" complexity. That's the reality of the situation as I see it.

      That's why when you can't do something via regex or can't figure out how particular feature of Perl regex implementation works or why it works in such a way, programming using index and substr is often the best and quickest alternative solution. The solution that, as I have found, works "well enough" even in cases were regex looks "the thing to use." KISS principle is about being simple, not about the most compact solution of a given problem (although it also has great value, if not taken to extremes).

      Your attitude "eliding mention of closures would mean there's no good way to explain grep, sort, or map or even lexical scope" is wrong and IMHO is the attitude of a "complexity junkie." Yes, you can explain closures using map or grep as examples where this notion is potentially useful, but not the other way around. You need to repent ;-)

      And please do not try to shoot the messenger. I know that writing a book is a very demanding, and not very rewarding occupation, with unfair criticism being one of the hazards of trade, and I commend you for publishing the "Modern Perl." Please consider my critique as the set of recommendations on how to improve it in future editions.

        There is no chapter about Perl ability to call C

        What I love about Modern Perl is that I can throw it at an accomplished programmer and they can "get" Perl really quickly. Because it is short. And well-written. And doesn't waste time on beginner stuff. So I personally applaud chromatic for focusing on the core language.

        Note that calling C from Perl (and vice versa) is covered in Extending and Embedding Perl (a 384 page book focusing just on that topic).

        There is no chapter about Perl debugger
        From one point of view, using tools -- such as a debugger, or profiler, or IDE, or refactoring browser, or static code analyser, or memory/cache/heap/thread checker, or code coverage analyser, or pod coverage analyser, or code formatter, or documentation generator, or ...) -- is not part of the language itself, and so has no place in a book focusing on that. Well, that is presumably the view taken by Modern Perl and The C++ Programming Language, for example.

        OTOH, Programming Perl (weighing in at 1176 pages!) does include a chapter on the Perl debugger. As does Mastering Perl.

        BTW, the list of famous programmers who dislike debuggers (or at least the time wasted in crack pipe debugging sessions) includes:

        • Larry Wall
        • Guido van Rossum
        • Randal L. Schwartz (If the code the client throws at you needs a debugger to trace it through, I'd argue it's not maintainable)
        • Linus Torvalds (I do not condone single-stepping through code to find the bug ... Without a debugger you have to look at the level above sources. At the meaning of things. You have to understand what the program does. Not just that particular line.)
        • Brian Kernighan and Rob Pike (Debugging statements stay with the program; debugging sessions are transient)
        • Rob Pike (If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs)
        • Uncle Bob Martin (Using a debugger is a code smell. I consider debuggers to be a drug -- an addiction. Programmers can get into the horrible habit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort.)
        • John Graham-Cumming (For me, a debugger is (almost) always the wrong tool. And people who habitually use debuggers are making a big mistake, because they don't truly understand their code. I suspect that the same people who use debuggers all the time, are the same people who don't unit test their code.)

        Update: Added some quotes from the famous programmers to indicate why they dislike debuggers.

        I'm also finding some of your review and critique bizarre and the reasoning as opaque as it is verbose. Good critiques are terse. Good writing is devoid of aphorism. Reviews should take a meta-view or risk becoming opinion editorial.

        As a 19 year user of Perl I could not possibly care less about Perls 1-4 except as they might relate to amusing stories from Wall and Co. As mentioned about other areas you found lacking, there are excellent books devoted to them already. No one is going to improve on Friedl's book(s) in regex for example.

        As a mostly self-taught programmer, and trained writer, I find chromatic's work above average, deeply helpful, and of great benefit to the community.

        You tried to remove all, even existing, links to the lower levels of abstraction (for example, by choosing to cover Moose and avoiding old school "bolted on" Perl OO mechanisms).

        You may have had a bad download and read only half of the book; the "Blessed References" section is not only in the same chapter as the "Moose" section, but they're right next to each other. Furthermore, the "Moose" section includes discussions of polymorphism, attributes, method dispatch, roles, and inheritance which would have been covered anyway even if Moose hadn't been covered.

Re: Modern Perl 4th Edition
by eyepopslikeamosquito (Chancellor) on Nov 20, 2017 at 06:52 UTC

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

Re: Modern Perl 4th Edition
by eyepopslikeamosquito (Chancellor) on Nov 18, 2017 at 04:09 UTC

    unhealthy infatuation with OO that Python promotes
    Let me tell you again that Python is a pragmatic multi-paradigm language - it does not have an unhealthy infatuation with OO. As I already pointed out, there are many languages with a stronger OO emphasis: Ruby, Smalltalk and Java to name just a few.

    It's early days yet, but I'm sorry to report that you are starting to show some eerie similarities to sundial namely:

    • Not providing citations to support your pet theories and strong opinions.
    • Re-posting the same flawed technical advice/opinion and home-spun wisdoms, even after they have been shown to be flawed.
    • Ignoring (or flatly rejecting without giving any reasons/citations) posts that demonstrate flaws in your posts.
    • Failing to read basic Perl documentation.
    • Posting at length on topics on which you have limited experience or expertise, such as OO and the perl tr operator.

Re: Modern Perl 4th Edition
by Anonymous Monk on Nov 17, 2017 at 19:38 UTC
    it took you 3 days to read the book and write a "review" that confirms your biases? go figure
Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: bookreview [id://1203697]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (14)
As of 2019-05-20 12:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you enjoy 3D movies?



    Results (128 votes). Check out past polls.

    Notices?