6 ms·
It seems that FP zealots have a hard time appreciating that there’s both a value and a cost to FP adherence. I find that FP forces too many contortions in the n
by jtdev 8y ago
It seems that FP zealots have a hard time appreciating that there’s both a value and a cost to FP adherence. I find that FP forces too many contortions in the name of some ethereal value without a consideration of cost.
- lolive 8y agoSame applies to OOP or imperative programming in general.
- test001only 8y agoI have seen this happen too - what would have been easier to understand is converted into this complex spaghetti of code, split across multiple files that it becomes difficult to understand, debug the flow. One example: Scala's implicit def could be misused in so many ways. It is described as "magic" in some tutorials...and that is a bad thing in my opinion.
- nickpsecurity 8y agoIt gets more cost-effective if combined with [semi-]automated tooling for verification, testing, and refactoring. Functional style makes these things easier. That's the draw in for me. So, I collect info on FP and verification followed by code generators and equivalence provers/testing for imperative and low-level forms of it. Examples include seL4 using Haskell->C, Lammich's functional->imperative converter for data structures, or maybe even compilers like CakeML.
- timbuckley 8y agoYou can have convoluted or simple FP programs as you can have the same for OOP. Nonetheless, is paradigm better at yielding more robust software you can reason about well more of the time? I would say yes, and FP does this.
- AnimalMuppet 8y agoIt depends on what the problem is. If the hardest part of of the problem is reasoning about the algorithm, then FP may be great. But then you get into things like hard real time, where the hardest part is reasoning about time. Or high-performance computing, where an essential part is controlling memory layout. Or... But you did say "more of the time" rather than "always", so I'm not actually disagreeing with you.
- craigsmansion 8y agoOnly in as far as elegance and predictability can be considered ethereal values in programming. > I find that FP forces too many contortions In light of their underlying computational models, functional programming really isn't the paradigm that is rife with contortion here.
- alexandercrohde 8y agoI think I know what you mean. I wouldn't use the word zealot as much as astronaut. FP Astronaut -- Super focused on hypothetical, academic, mathematical concerns and random performance optimizations (e.g. tail recursion) over clarity. I think scala's Slick library is an example of this. FP Pragmatist -- Concerned about clarity, debugging, logging, correctness, readability by all skill levels, modifiability, documentation, the common cases first and the extreme cases last I think you can be a big FP advocate without being an off-putting incomprehensible blowhard
- julesnp 8y agoI've never heard of tail recursion being used as a performance optimization. Generally it's required to prevent a recursive function from blowing the stack. Iteration is usually more performant than recursion, but doesn't mix well with immutability.
- Technetium_Hat 8y agoTail calls _are_ iteration, just expressed as a function.
- yakshaving_jgt 8y agoOh, there's cost. But in my experience, that cost is still cheaper than any of the alternatives.