|
in reply to To use or not to use OO Perl
For interface sanity, clean encapsulation and maintenance purposes use OO, for run time speed use FP (functional programming), for implementation speed use Imperative programming, for fun use all of the above.
I have this feeling however that the "functional" approach you mean is really the "imperative" approach and not what most folks here would call "functional programming"
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
Flux8
|
Re^2: To use or not to use OO Perl
by FoxtrotUniform (Prior) on Oct 22, 2004 at 18:34 UTC
|
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"?
| [reply] |
|
|
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
| [reply] |
|
|
| [reply] |
Re^2: To use or not to use OO Perl
by SpanishInquisition (Pilgrim) on Oct 25, 2004 at 17:26 UTC
|
For interface sanity, clean encapsulation and maintenance purposes use OO,
I do not think OO is more maintainable when you are comparing advanced programmers to advanced programmers.
Hybrid functional development allows functional programming with objects. Even Lisp has structures.
FP code in itself can be incredibly easy to maintain, especially because the chain of function calls is usually very short and direct ... that, and short automagical functions are encouraged.
OO does an excellent job, though, when you really can't trust everyone in the codebase. It defines boundaries, rules, and operations ... a well defined and documented API does this in the same way, though it doesn't force a design methodology on the entire codebase and through every class/source file.
| [reply] |
|
|
I do not think OO is more maintainable when you are comparing advanced programmers to advanced programmers.
True. Advanced programmers tend to push the envelope regardless of the technology involved. :-)
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
Flux8
| [reply] |
|
|
