Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re^2: To use or not to use OO Perl

by FoxtrotUniform (Prior)
on Oct 22, 2004 at 18:34 UTC ( #401627=note: print w/ replies, xml ) Need Help??


in reply to Re: To use or not to use OO Perl
in thread To use or not to use OO Perl

for run time speed use FP (functional programming)

Huh? Functional programming tends to be pretty expensive in terms of memory and arguably slower than a more procedural style (depending on whether your language of choice does tail-call optimization). Side effect-free programming with lots of first-class functions, closures, and lambdas floating around isn't easy to optimize. The traditional check-box feature of functional programming is implementation speed. (On the other hand, ghc can produce some damn fast code; on the gripping hand, gcc can beat ghc pretty handily. IME, of course.)

Functional programming techniques make some faster algorithms easier to write (divide and conquer, for instance; languages with lazy lists make dynamic programming absurdly easy). That's not necessarily the same thing, though.

Maybe by "functional" programming you mean "procedural"?

--
Yours in pedantry,
F o x t r o t U n i f o r m

"Lines of code don't matter as long as I'm not writing them." -- merlyn


Comment on Re^2: To use or not to use OO Perl
Re^3: To use or not to use OO Perl
by demerphq (Chancellor) on Oct 22, 2004 at 19:05 UTC

    No, I mean mostly code generation using closures and string eval. If you write code that writes code then you can usually make that generated code extremely efficient. A good example for me was a system that processes large volumes of records based on a config file of rules that were strongly influenced by file type. Instead of making a machine in perl that processed the records according to the rules I made a machine in perl that created perl programs that were equivelent to the rules for each type of file. Each closure was constructed to handle only the rules for each file and in an optimised way. The end result has proved to be extremely fast.

    Im not sure if im abusing the term functional programming here, but it seems to me that this kind of thing is indeed a form of it. Anyway, hope this makes some sense, im not feeling particularly expressive right now. :-)


    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi

      Flux8


      No, I mean mostly code generation using closures and string eval. If you write code that writes code then you can usually make that generated code extremely efficient. A good example for me was a system that processes large volumes of records based on a config file of rules that were strongly influenced by file type. Instead of making a machine in perl that processed the records according to the rules I made a machine in perl that created perl programs that were equivelent to the rules for each type of file. Each closure was constructed to handle only the rules for each file and in an optimised way. The end result has proved to be extremely fast.

      Regardless of whether or not "writing code that writes code" is "really" functional programming, that sounds like a really cool CUFP or Meditation waiting to happen.

      --
      Yours in pedantry,
      F o x t r o t U n i f o r m

      "Lines of code don't matter as long as I'm not writing them." -- merlyn

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (5)
As of 2014-12-21 04:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

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





    Results (102 votes), past polls