4 ms·

> Ideally, a good compiler that understands FP will, behind the scenes, detect when it's safe to mutate the old data rather than creating a copy. That's a big p

> Ideally, a good compiler that understands FP will, behind the scenes, detect when it's safe to mutate the old data rather than creating a copy. That's a big part of why Haskell manages to be neck-and-neck with C despite being functionally pure. Not talking against Haskell or FP; The disadvantage is being hard to reason about performance. Ensuring compiler will optimize something will take more cognitive load than simply writing straightforward code. Imagine having a map() method on an array that produces another array. In a long chained pipeline of such things, compiler may be able to elide extra allocations and generate asm very near to handwritten for loops. But the abstraction breaks when the method does I/O or has side effects - you can't reorder anything in order to elide allocations. (Well this example may not make sense in Haskell because Haskell is lazily evaluated). However there is a limit to what compiler can do, and it might manifest in edge cases like variation in order of imports. I'd rather have straightforward code than relying on compiler optimizations. I am not arguing "against abstractions" like some Go fanboys tell you map and filter are less efficient. It is always possible to apply same map filter to iterators/lazy streams instead of arrays and get same performance in straightforward code. But that's not same as keeping in mind what heuristics compiler uses to optimize the code.

hopia 6y ago
I suppose in FP/Haskell you would structure your code differently, so that it wouldn't have side effects when mapping arrays. That way you could even parallelize it trivially. High level languages produce a lot less code than than less optimized implementations. Difficulties with reasoning about execution/performance is the penalty you potentially have to pay. In my experience it indeed may be hard to understand performance with Haskell. That said, it comes with excellent tooling to overcome it in most of the cases.

hopia 6y ago

I suppose in FP/Haskell you would structure your code differently, so that it wouldn't have side effects when mapping arrays. That way you could even parallelize it trivially. High level languages produce a lot less code than than less optimized implementations. Difficulties with reasoning about execution/performance is the penalty you potentially have to pay. In my experience it indeed may be hard to understand performance with Haskell. That said, it comes with excellent tooling to overcome it in most of the cases.