←back to thread

Why Isn't Functional Programming the Norm? [video]

(www.youtube.com)
296 points gyre007 | 1 comments | 17 Oct 19 10:10 UTC | HN request time: 0.205s | source
Show context
_han ◴[17 Oct 19 11:49 UTC] No.21281004[source]▶
The top comment on YouTube raises a valid point:

> I've programmed both functional and non-functional (not necessarily OO) programming languages for ~2 decades now. This misses the point. Even if functional programming helps you reason about ADTs and data flow, monads, etc, it has the opposite effect for helping you reason about what the machine is doing. You have no control over execution, memory layout, garbage collection, you name it. FP will always occupy a niche because of where it sits in the abstraction hierarchy. I'm a real time graphics programmer and if I can't mentally map (in rough terms, specific if necessary) what assembly my code is going to generate, the language is a non-starter. This is true for any company at scale. FP can be used at the fringe or the edge, but the core part demands efficiency.

replies(29): >>21281094 #>>21281291 #>>21281346 #>>21281363 #>>21281366 #>>21281483 #>>21281490 #>>21281516 #>>21281702 #>>21282026 #>>21282130 #>>21282232 #>>21283002 #>>21283041 #>>21283257 #>>21283351 #>>21283424 #>>21283461 #>>21285789 #>>21285877 #>>21285892 #>>21285914 #>>21286539 #>>21286651 #>>21287177 #>>21287195 #>>21288087 #>>21288669 #>>21347699 #
Ragib_Zaman ◴[17 Oct 19 12:31 UTC] No.21281291[source]▶
Perhaps not a satisfactory response but when I start drifting towards thinking FP is fundamentally not as performant as _whatever_else_, I remember that Jane Street uses OCaml basically from top to bottom, and they certainly can't be too slow... Some black magic going on there.
replies(4): >>21281341 #>>21281597 #>>21281921 #>>21287795 #
1. samvher ◴[17 Oct 19 13:40 UTC] No.21281921[source]▶
There are really many places in code where you really don't care about performance that much. And in that case conciseness/expressiveness/correctness can be extremely valuable.

Also there are different aspects to performance, and when (for example) it comes to latency, a platform like Erlang/BEAM makes it particularly easy to get low latency in certain contexts without thinking about implementation much. In Haskell you can accomplish similar things with green threads. It will probably need more clock cycles for a given action than a tuned C implementation but that's not always what matters, and the code will probably be cleaner.