Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re: Re: Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)

by diotalevi (Canon)
on Jun 26, 2003 at 02:23 UTC ( #269088=note: print w/ replies, xml ) Need Help??

in reply to Re: Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)
in thread Closure on Closures

In short, (in Perl at least) closure is faster than object due to less dereferencing overhead but could be slower due to larger memory requirement? (In the test, the edge of closure over object was diminishing and even reversed when the tasks were getting more "heavy-duty.")
No, larger just means larger (unless you get so large you swap). Heavy use of closures would make me at least consider memory usage.

How would you characterize and procedurize a "functional design process" (if there is such a thing). Like a user manual on Design: the Functional (or Closure) Way.
I read two distinct thoughts in the rest of your question. Design by documentation and programming style. The programming style question is likely best answered by pointing you to Why I like functional programming. My own coding style is largely procedural for the smaller cases, object oriented for the larger picture with plenty of functional goodness. Most of my exposure to logical programming comes from SQL and XSLT (which I adore). The point is that for common, every day programming there is a lot to be gained by being flexible and drawing from many disciplines.

It lets me get my work done and done right.

As for programming by documentation, I'm playing with that right now. For the project I'm on I've been writing the documentation for processes that the code implements and then just like mortar, filling actual code in after the fact. So far its a dream. I think other people call this ``Design by Contract'' but I couldn't swear to that. In fact, there's a module Class::Contract which purports to help you write code that way (though if you read just the documentation you won't understand DoC).

Comment on Re: Re: Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)
Re: Re: Re: Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)
by chunlou (Curate) on Jun 26, 2003 at 03:11 UTC
    My question was also intended to be a pedagogical one, though I might or might not have conveyed that notion.

    Perhaps I rendered the wrong idea when I used words like "characterize" or "procedurize" (I don't know if such word even exists).

    Design is a creative process. I don't think anyone can "mechanicalize" (another makeup word?) it. But people certainly have explicit or implicit theories behind their minds guiding their thinking and design process.

    Perhaps what I'm trying to ask is, what are the guiding theory of "closure"?

    Stated "theories" accompanied with examples are important when teaching someone something new, just as foreign language teachers teach grammar. People who already speak the language don't think grammar. Programmers who already master the trade don't think of what paradigm, theory or style they're actually employing.

    But for a student, he might be more explicitly and discretely thinking of "encapsulation," "interfaces," "inheritance," etc. one by one, rather by utilizing every appropriate thing dexterously without thinking of all those "labels." It's just a natural learning process.


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2014-09-02 03:16 GMT
Find Nodes?
    Voting Booth?

    My favorite cookbook is:

    Results (18 votes), past polls