Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^4: Real life uses for closures. (update: disambiguation)

by BrowserUk (Pope)
on Feb 13, 2013 at 18:35 UTC ( #1018597=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Real life uses for closures. (update: disambiguation)
in thread Real life uses for closures.

I've been reading a lot about constructing interpreters and VMs lately, and one thing that seems common to most new ones is the seemingly obligatory inclusion of closures; and the almost equally obligatory tales of woe, sleepless nights and extreme programming hardship that are required in order to implement them in an efficient and elegant manner.

Then the thought that formed in my mind was that whilst I am quite happy to make extensive use of them, I was also quite happily solving my programming problems in languages that don't support them for 15+ years before I became acquainted with them.

So then the questions that came to me were: a) how much use do people make of them in Perl? b) How many of those uses are actually 'killer applications' of closures, rather than trivial or convenient uses of up-values in anonymous subroutines that could just as easily be done using some other mechanism that doesn't impose such demands upon the VM?

One of the 'killer applications' of closures often cited in FP circles, is their links to continuation passing. But continuation passing is just one method of solving a problem that can be solved in various other ways. And most of those other ways seem to impose far less runtime burdens than CP whilst achieving the same goals.

Hence my very open question to try and get a feel for what people do with closures in real-world code.


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.


Comment on Re^4: Real life uses for closures. (update: disambiguation)
Re^5: Real life uses for closures. (update: disambiguation)
by LanX (Canon) on Feb 13, 2013 at 23:25 UTC
    > I was also quite happily solving my programming problems in languages that don't support them for 15+ years before I became acquainted with them.

    I agree and as I said closures are somehow the other side of the OO coin in allowing encapsulated variables.

    Just more elegantly done with less code in most languages.

    It's like saying why do we need lexical variables, as long as we care about chosing the right package-namespaces we can achieve the same. True, but most of us don't wanna code Perl4 anymore!

    > I've been reading a lot about constructing interpreters and VMs lately, and one thing that seems common to most new ones is the seemingly obligatory inclusion of closures;

    I think it's also part of the feature competition. Like "What you have no App to shave your legs on your new smartphone"?

    OTOH what I really like about JS is that it does FP (almost¹) excatly like Perl, while Ruby and Python suck at closure side-effects.

    IMHO it's far easier to port FP-patterns than OO-patterns, and closures are indispensable for it.²

    Saying this you might have noticed that some participants in this thread didn't really know what closure.

    So yes you, can be a very efficient programmer w/o closures.

    Cheers Rolf

    ¹) well exactly if you have a dialect allowing to swap var with let.

    ²) And we have this "one package per file" paradigm, which forbids to just add another encapsulation on the fly. (No fun discussing the perl critic addicts)

    IIRC correctly there was a nice thread where GrandFather solved a problem with an embedded mini-class where I used closures... If I can find it, I'll update.

      I agree and as I said closures are somehow the other side of the OO coin in allowing encapsulated variables.

      Indeed. One of my very early posts here was a OO class that used closures to produce a JS-style prototypical OO mechanism.

      Looking back at it I'm not sure it'll win any plaudits for maintainability, but it was a great tool for learning the power and limitations of closures.

      It's like saying why do we need lexical variables, as long as we care about chosing the right package-namespaces we can achieve the same.

      I appreciate the analogy, but if you look back, I wasn't reaching any conclusions with my thoughts about closures, just examining the evidence.

      As with many other ideas that suddenly gain currency -- despite usually having been around in one form or another since the '60s or early '70s -- I like to examine 'new ideas' every so often and try to see through the theory-wash, marketing speak and hyperbole, and reach my own conclusions as to their usefulness and importance.

      Through this process I have avoided getting swept alone by many a fad that has subsequently shown itself to be of dubious value. I tend to apply the same criteria to most everything in life.

      As far as closures go; I think I reached the conclusion that they are a valuable addition to languages so long as their implementation does not exact too high a price on the performance of the rest of that language.

      Done right, they are a useful addition to the toolbox; but I wouldn't want to throw out (or ham-string performance-wise) too many of the other tools in the box to accommodate them.

      Continuation passing on the other hand seems to exact too high a price.

      I think it's also part of the feature competition.

      That's essentially what I was wondering. Are closures just another 'we must have that too' kick.

      I think they are somewhat more than that.

      Saying this you might have noticed that some participants in this thread didn't really know what closure.

      Indeed. But that is also true of many a dissertation on them that you'll find online.

      But when I first encountered SmallTalk's block arguments; their significance was lost on me also.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
Re^5: Real life uses for closures. (update: disambiguation)
by davido (Archbishop) on Feb 14, 2013 at 08:27 UTC

    Apparently they're seen as useful enough that C++11 got them, in its own C++ish way. You're probably already familiar with this new addition to C++, but just in case, C++ lambda functions can capture the state of their enclosing scope. The consensus seems to be that adding this feature to C++ was a big win for the language... something Perl's been doing for decades.

    An introductory article on C++11's lambda closures.

    One difficulty that C++'s "closures" have is that you can't really share a variable from an enclosing scope across several lambda functions if the variable's outer scope ends. This is because the way C++ implements them, the captured variables are either copies, or references. Copies can't really be shared. References can, but if the target falls out of scope the lambdas are left holding the bitter end of an unfastened rope.

    But all is not lost; C++11 got shared reference counted pointers too.


    Dave

      Yes. I watched (the video of) Stroustrup's keynote There are some very interesting features in it; and some disappointments over what didn't get in.

      The only problem is it'll probably be 2015 at least before the major compilers fully support the standard; and around 2025 before major projects will consider it safe to use any of the new features. :(

      I mean C99 introduced inline functions which are a far better choice for most things that use those horrible multi-line extended macros that litter most OSS libraries and projects, but still you find those 30 line #define macros everywhere because -- apparent -- there may be some user in Outer Mongolia that still hasn't got a C99 compiler.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        In the case of C++11, the major compilers already support most of it. g++ is lacking on its regular expression support, and MSVC++ was a little slow with variadic templates, but I think they're implemented now. Most of what is most important is there; move semantics, rvalue references, ranged loops, auto and decltype, modified return value function syntax, reference counted pointers, lambdas, and so on.

        But your second point is right on the mark; though everyone's excited to use these new features, often the new features are avoided in the name of backward compatibility, and I haven't a good feel for C++11 features being accepted into newer projects.

        I can say that the standard library has been rewritten in most major implementations to take advantage of move semantics, which is a really big win that nobody really sees -- like trie optimization in Perl's regexes, it's just there behind the scenes.

        Anyway.... I've taken us way off topic. I apologize for rambling in your thread. :)


        Dave

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2014-12-25 10:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (160 votes), past polls