Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

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

by chunlou (Curate)
on Jun 26, 2003 at 01:50 UTC ( #269083=note: print w/ replies, xml ) Need Help??


in reply to 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.")

Different question, if I may. I want to focuse on Design, as opposed to Programming.

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 hope it's self-evident that design and programming are not always an integrated process. Many people program in Java the imperative or procedural way pretty much, nothing so OO about the design of the codes.

On the other hand, a design framework could be applied more generally even when the tools are not integrated with it. Like, OO Design is a good framework to guide your thinking process to characterize and generalize some human verbal requirements into classes. For instance, you could think of a Webpage being a class and the stored procedure associated with it being methods, even though HTML, SQL, etc are not OO.

Besides the characterization of the process, what would be the examples constrasting the closure/functional of design versus the other whatever ways, along with the advantages--design-wise or conceptual--such as being more succinct, flexible, insightful, etc? (Like, in physics, some people do things the group-theoretic way vs. the good old calculcus way; in economics, game-theoretic vs others. They produce different insights into the same problems and sometimes even different conclusions.)

Take the scripts in the test as examples. Closure counter certainly looks like a cleaner design (or model); object is probably an overkill in this case. With the Turtle, if we need more "methods," object seems like a natural way to go. With directory iterator, I really have no preference towards either.

Thanks.

_______________________
Update: As a afterthought, maybe some examples on translating some existing OO design/code into closure one (if applicable) would be pedagogically more instructive? Since I suppose more people can relate to OO than closure.


Comment on Re: Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)
Re: Re: Re: Re: (On Speed Diff, etc.) Closure on Closures (beta)
by diotalevi (Canon) on Jun 26, 2003 at 02:23 UTC

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

      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.

      Thanks.

Log In?
Username:
Password:

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

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

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (170 votes), past polls