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"?

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

For interface sanity, clean encapsulation and maintenance purposes use OO,

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.

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