in reply to Re: Memory efficiency, anonymous vs named's vs local subroutines
in thread Memory efficiency, anonymous vs named's vs local subroutines

Hello AnomalousMonk,

Thank you for your time and effort. You are right, no matter what tutorial, article I read all they say the same. The possibility when you nesting functions to mess up your code is really high. You assume that your code does one thing, but in reality it does 10 others on the background.

I will stick in simple named functions, for every simple implementation called at the main script.

Seeking for Perl wisdom...on the process of learning...not there...yet!

Replies are listed 'Best First'.
Re^3: Memory efficiency, anonymous vs named's vs local subroutines
by AnomalousMonk (Archbishop) on Jul 18, 2015 at 21:14 UTC
    I will stick in simple named functions...

    Simplicity is always a good goal and a good yardstick for judging your code. But I don't want to discourage you from using anonymous lexical subroutines: they work, and they work the way you think they work! In fact, Dominus wrote a whole book (freely available here — and highly recommended!) that's essentially just a zillion ways to use anonymous lexical subroutines.


    Give a man a fish:  <%-(-(-(-<

Re^3: Memory efficiency, anonymous vs named's vs local subroutines
by Laurent_R (Canon) on Jul 19, 2015 at 10:05 UTC
    I will stick in simple named functions
    For usual plain-vanilla subroutines, e.g. just pieces of code that you want to use several times and/or call from different places in your program, and that will usually take zero, one or more input parameter(s) and return one or more return value(s), named subroutines are certainly simpler, easier to understand and to maintain. And that's what I would be using in such cases.

    There are, however, some slightly more advanced techniques that are using anonymous subs and give you a lot of power, just as references to anonymous arrays and hashes allow you to build nested data structures (arrays of arrays, arrays of hashes, etc.) that would be very tedious or in some cases next to impossible to build with named arrays or named hashes.

    I would also recommend to every reader the Higher Order Perl book, by Mark Jason Dominus, mentioned above by AnomalousMonk, in my view the best CS book I've read in the last ten years. It is available on line on the author's site. Just one word of warning, though: it is not for pure beginners, you need to have at least an intermediate level Perl to really take advantage of it (although the first 2 or 3 chapters are probably accessible to "advanced beginners").

    Among the things that anonymous functions make possible or, at least, make usually much easier or more generic:

    • Callback functions (subs passed as a parameter to another sub)
    • Dispatch tables (arrays or hashes of code refs to define program behavior depending on a certain parameter)
    • Function generators and function factories (functions that return many other functions depending on the input parameters)
    • Iterators (functions returning values usually one at a time, on demand)
    • Closures (functions that maintain alive part of their run-time environment)
    • More generally, higher-order functions and abstract generic functions, and quite a few other things that I can't explain in just one line here.
    In very strict terms, probably none of the techniques above absolutely requires anonymous subs, but only using anonymous subs will really unleash their full power.