Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

Re^2: Modern Perl 4th Edition

by likbez (Acolyte)
on Nov 19, 2017 at 03:11 UTC ( #1203761=note: print w/replies, xml ) Need Help??

in reply to Re: Modern Perl 4th Edition
in thread Modern Perl 4th Edition

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.

Replies are listed 'Best First'.
Re^3: Modern Perl 4th Edition (Debuggers)
by eyepopslikeamosquito (Chancellor) on Nov 19, 2017 at 07:10 UTC

    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.

Re^3: Modern Perl 4th Edition
by Your Mother (Bishop) on Nov 19, 2017 at 03:42 UTC

    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.

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

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2019-06-24 17:36 GMT
Find Nodes?
    Voting Booth?
    Is there a future for codeless software?

    Results (99 votes). Check out past polls.