14 ms·
For me functional languages lose to imperative ones because they make it harder to reason about what actually happens when the program is executed. When you see
by eterevsky 5y ago
For me functional languages lose to imperative ones because they make it harder to reason about what actually happens when the program is executed. When you see a nested loop, you immediately know that it will probably perform O(n^2) operations. This is not so in functional languages. I clearly understood it when I was reading about Haskell and learned that out of `foldl` and `foldr` one works in constant time and another in linear. I don't remember which.
- garethrowlands 5y agoHaskell execution's definitely tricky to reason about. Though, a declarative doesn't always lose. The obvious counter example is SQL, which replaced imperative approaches.
- cousin_it 5y agoBoth have to consume the whole list, so none of them can be constant. You're probably thinking of space complexity, and yeah, in Haskell it's even more tricky - it depends on how the function's caller uses the result.
- sullyj3 5y agoIt depends on the domain. In performance critical code, I agree that it usually makes sense to use an imperative language. However, not all code is performance critical. Also note none of this is to say that fp is inherently incapable of high performance code - properly tuned Haskell can be competitive with C. Libraries like Streamly[1] are designed with extremely high performance in mind. But I agree reasoning about performance is much more difficult and requires more expertise. [1] https://hackage.haskell.org/package/streamly https://hackage.haskell.org/package/streamly