Hacker News Reader

Comment by jtdev | Hacker News Reader

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.

View on HN

I 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

I'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.

Tail calls _are_ iteration, just expressed as a function.

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

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

Same applies to OOP or imperative programming in general.

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

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

Oh, there's cost. But in my experience, that cost is still cheaper than any of the alternatives.

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

Reply on news.ycombinator.com