5 ms·

> FP's conceit is trading performance for correctness. This isn't even remotely the case. The most popular functional languages are substantially faster than

> FP's conceit is trading performance for correctness. This isn't even remotely the case. The most popular functional languages are substantially faster than the most popular imperative languages. Haskell or OCaml both smoke the top 3 imperative languages: Python, Java, JavaScript. The "conceit" is trading the conceptual model most people learn in high school/trade programming classes for correctness, with little to no bearing on performance. > Rust is, as far as I'm aware, the first language that allows you to deploy functional concepts as zero-cost abstractions. This is definitely not the case. You can deploy zero-overhead functional concepts in C++ using template programming, constexprs, etc. Also, "zero-overhead" compared to what? Plenty of functional language have abstractions that can reasonably be described as zero-overhead, like newtypes in Haskell or functorial modules in OCaml. You can even translate the non-monomorphically-recursive subset of Haskell to pure hardware, which is pretty much the definition of "zero overhead". This article reads more like a regurgitation of taglines than original thinking.

bigdubs 6y ago
You're mixing compiled versus interpreted languages here.
- centimeter 6y ago
  I'm responding to the article, which made the claim that the tradeoff when using a functional language is performance vs correctness. This is obviously not true in any meaningful capacity, when the vast majority of imperative language deployments are using languages slower than the vast majority of functional language deployments. The fact that the most popular imperative languages are usually JIT compiled (not interpreted, except python) instead of statically compiled is not relevant to the argument.
  - mcqueenjordan 6y ago
    The claim wasn't "most popular vs. most popular". Why don't you choose "highest performance `FP language` vs highest performance `imperative language`"? Also, `FP language` and `imperative language` aren't well-defined concepts (nor can they be, frankly). These are paradigms that languages have varying degrees of support for. So the entire foundation of the argument is meaningless.
marta_morena_28 6y ago
It's actually even worse than that. Functional programming is on pretty much all accounts FASTER than imperative programming by design. Imperative programming heavily relies on state mutation and branching. FP relies on immutability, purity and streaming. Essentially all those are properties that make code faster/parallelizable. Yes, you can usually write SOME imperative form of an algorithm that is faster than its FP counterpart, but generally it will be much less readable and maintainable. The beauty about FP is that you can get readable, maintainable code that is often on par or faster than "good looking" imperative code and also parallelizable. Writing imperative, parallel code is often an absolute nightmare, that any entry level programmer and even experienced programmers will get wrong.
- staticassertion 6y ago
  In theory purity unlocks optimizing potential, but in practice I don't think what you're saying holds true. Mutating a value is almost always cheaper than allocating a new version of that value and collecting the old one. I think you're vastly understating the "you can usually" and overstating the "much less readable and maintainable".
- chmln 6y ago
  Almost every point made here is basically false. The best performing languages are imperative (C, C++, Rust), with functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads. Whatever properties were supposed to make it faster/parallelizable have clearly not manifested themselves very well after decades. Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go.
  - centimeter 6y ago
    > functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads Not even the most contrived benchmark games place functional languages an order of magnitude slower than C. Maybe 2-5 times slower on average. Of course, this doesn’t actually matter, because 95% of apps are performance constrained because of architectural reasons, and functional languages tend to scale better in terms of architectural asymptotics. > Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go. Go is, by all accounts, a massive nightmare. I think this claim calls your judgement into question.
jeff-davis 6y ago
The article shouldn't have brought up points about FP performance that it couldn't really support. But it's interesting content overall and that was a side point.
- atoav 6y ago
  I am not too familiar with FP languages, but I must say I have never seen a FP language in low level embedded or GPU code. Of course there are garbage collected imperative languages which are slower than say Haskell, but can Haskell's speed compare to the most efficient C implementation of a code without making it unreadable? This is what Rust's promise of "zero cost abstractions" means: if you went all in and handcrafted every pointer it wouldn't become more efficient then it is in it's abstracted form. Again, I don't know enough about FP languages to make qualified statements, but I thought this was a Rust novelty.
  - afiori 6y ago
    OCaml allegedly has some success stories for this.
    - atoav 6y ago
      Thanks for the tip
  - SAI_Peregrinus 6y ago
    https://clash-lang.org/ https://clash-lang.org/ is a functional HDL. Compiles to VHDL, Verilog, or SystemVerilog. That's lower level than just about anything else you can get code for (I suppose SPICE is even lower level in this sense...)

bigdubs 6y ago

You're mixing compiled versus interpreted languages here.

centimeter 6y ago
I'm responding to the article, which made the claim that the tradeoff when using a functional language is performance vs correctness. This is obviously not true in any meaningful capacity, when the vast majority of imperative language deployments are using languages slower than the vast majority of functional language deployments. The fact that the most popular imperative languages are usually JIT compiled (not interpreted, except python) instead of statically compiled is not relevant to the argument.
- mcqueenjordan 6y ago
  The claim wasn't "most popular vs. most popular". Why don't you choose "highest performance `FP language` vs highest performance `imperative language`"? Also, `FP language` and `imperative language` aren't well-defined concepts (nor can they be, frankly). These are paradigms that languages have varying degrees of support for. So the entire foundation of the argument is meaningless.

marta_morena_28 6y ago

It's actually even worse than that. Functional programming is on pretty much all accounts FASTER than imperative programming by design. Imperative programming heavily relies on state mutation and branching. FP relies on immutability, purity and streaming. Essentially all those are properties that make code faster/parallelizable. Yes, you can usually write SOME imperative form of an algorithm that is faster than its FP counterpart, but generally it will be much less readable and maintainable. The beauty about FP is that you can get readable, maintainable code that is often on par or faster than "good looking" imperative code and also parallelizable. Writing imperative, parallel code is often an absolute nightmare, that any entry level programmer and even experienced programmers will get wrong.

staticassertion 6y ago
In theory purity unlocks optimizing potential, but in practice I don't think what you're saying holds true. Mutating a value is almost always cheaper than allocating a new version of that value and collecting the old one. I think you're vastly understating the "you can usually" and overstating the "much less readable and maintainable".
chmln 6y ago
Almost every point made here is basically false. The best performing languages are imperative (C, C++, Rust), with functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads. Whatever properties were supposed to make it faster/parallelizable have clearly not manifested themselves very well after decades. Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go.
- centimeter 6y ago
  > functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads Not even the most contrived benchmark games place functional languages an order of magnitude slower than C. Maybe 2-5 times slower on average. Of course, this doesn’t actually matter, because 95% of apps are performance constrained because of architectural reasons, and functional languages tend to scale better in terms of architectural asymptotics. > Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go. Go is, by all accounts, a massive nightmare. I think this claim calls your judgement into question.

jeff-davis 6y ago

The article shouldn't have brought up points about FP performance that it couldn't really support. But it's interesting content overall and that was a side point.

atoav 6y ago
I am not too familiar with FP languages, but I must say I have never seen a FP language in low level embedded or GPU code. Of course there are garbage collected imperative languages which are slower than say Haskell, but can Haskell's speed compare to the most efficient C implementation of a code without making it unreadable? This is what Rust's promise of "zero cost abstractions" means: if you went all in and handcrafted every pointer it wouldn't become more efficient then it is in it's abstracted form. Again, I don't know enough about FP languages to make qualified statements, but I thought this was a Rust novelty.
- afiori 6y ago
  OCaml allegedly has some success stories for this.
  - atoav 6y ago
    Thanks for the tip
- SAI_Peregrinus 6y ago
  https://clash-lang.org/ https://clash-lang.org/ is a functional HDL. Compiles to VHDL, Verilog, or SystemVerilog. That's lower level than just about anything else you can get code for (I suppose SPICE is even lower level in this sense...)