4 ms·

It's actually even worse than that. Functional programming is on pretty much all accounts FASTER than imperative programming by design. Imperative programming h

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.
  - sebmellen 6y ago
    > Go is, by all accounts, a massive nightmare. All accounts? That's a pretty strong claim. Go works well at Google.
  - ncmncm 6y ago
    The final remark about Go is the only possibly valid remark.
    - cy_hauser 6y ago
      I've used Go for both "web routing" and business logic apps and found it fairly nice. In what context and in what way do you find it a bad?
      - ncmncm 6y ago
        Go was designed as a language with fairly good performance, but with limited capability so that programmers with limited skills would find it hard to get too far into the weeds. It is well suited to undemanding tasks. Most programming tasks are undemanding, and most programmers have limited skills, so it is a good match for a great deal of routine work. It fits in the same niche as Java, where Java's OO apparatus imposes complications that are superfluous for simple applications, and an actual obstacle in most. So, a language that abandons all that is better in those applications. Simple tools are not bad except when you need something more. So, my agreement was with the idea in mind of writing Pandoc in Go, which would be madness.
        cy_hauser 6y ago
        Thanks for the details. I hear what you've said. I agree that Go was built with limited capability in order to make it easy for junior developer. And I agree it can slow down more senior developers at times. Although not nearly as much as I expected when I first started using it. I don't know Pandoc so I'll take your word for it. I'll also agree that there are entire of classes that Go isn't sell suited for, but we'll have to disagree as to whether it's limiting for the types of applications it was created for. I must not be building the same class of application as you are.
winstonewert 6y ago
You need to stop reading fp propaganda
nine_k 6y ago
This mixes up a few things. Immutable data means lack of aliasing problems (two pointers to a mutable cell). There are other languages that have this property, notably Fortran. It does allow many speed optimizations, in both parallel and single-thread cases. Yes, this is one of the reasons why Fortran is routinely faster than C on numeric code, and even Haskell sometimes is, too. It is theoretically proven that any algorithm which uses mutable data can be converted to use immutable data with a penalty on memory and time not exceeding O(log n). In absolute terms, such a penalty can be low, or pretty high (consider working with large bitmaps). There's no silver bullet. Functional code is often preferred due to its clarity, both humans and machines have easier time reasoning about it, and even formally proving its properties. Sometimes it is just more important than raw speed, but sometimes allows for more aggressive optimizations (rewriting by the compiler) and higher speed.
- marcinzm 6y ago
  >Functional code is often preferred due to its clarity, both humans and machines have easier time reasoning about it, and even formally proving its properties. Sometimes it is just more important than raw speed, but sometimes allows for more aggressive optimizations (rewriting by the compiler) and higher speed. I'm curious if that's really the case in practice. Functional code allows for clever concise implementations and clever concise implementations are notoriously hard to read. Go, for example, is often lauded for it's readability due to it's more verbose and non-clever nature. edit: To clarify, I mean readability by the above-average programmer not by a world expert who has spent 15 years becoming one with the language.
p0nce 6y ago
Where are all the FP competitors for fast programs then?
imtringued 6y ago
It's very easy to disprove this comment. Haskell is pure functional language and uses linked lists as their main list data structure. This is because it is difficult to modify individual elements in an array in a purely functional manner without copying the entire array. Meanwhile using arrays in C or Rust and changing individual elements is not only very easy, it's very fast as well. The default string implementation in Haskell is built on a linked list of characters and it performs horribly, so Haskell has multiple string implementations. The default string implementation is still often used because it is more convenient. This is an example where writing more readable code also involves making it perform worse. Rephrased: Faster code is less readable in Haskell. https://stackoverflow.com/questions/13865420/why-is-haskells-default-string-implementation-a-linked-list-of-chars https://stackoverflow.com/questions/13865420/why-is-haskells...
- centimeter 6y ago
  The text type everyone uses in Haskell is Data.Text, which is packed. String is not used for anything performance-sensitive.

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.
- sebmellen 6y ago
  > Go is, by all accounts, a massive nightmare. All accounts? That's a pretty strong claim. Go works well at Google.
- ncmncm 6y ago
  The final remark about Go is the only possibly valid remark.
  - cy_hauser 6y ago
    I've used Go for both "web routing" and business logic apps and found it fairly nice. In what context and in what way do you find it a bad?
    - ncmncm 6y ago
      Go was designed as a language with fairly good performance, but with limited capability so that programmers with limited skills would find it hard to get too far into the weeds. It is well suited to undemanding tasks. Most programming tasks are undemanding, and most programmers have limited skills, so it is a good match for a great deal of routine work. It fits in the same niche as Java, where Java's OO apparatus imposes complications that are superfluous for simple applications, and an actual obstacle in most. So, a language that abandons all that is better in those applications. Simple tools are not bad except when you need something more. So, my agreement was with the idea in mind of writing Pandoc in Go, which would be madness.
      - cy_hauser 6y ago
        Thanks for the details. I hear what you've said. I agree that Go was built with limited capability in order to make it easy for junior developer. And I agree it can slow down more senior developers at times. Although not nearly as much as I expected when I first started using it. I don't know Pandoc so I'll take your word for it. I'll also agree that there are entire of classes that Go isn't sell suited for, but we'll have to disagree as to whether it's limiting for the types of applications it was created for. I must not be building the same class of application as you are.

winstonewert 6y ago

You need to stop reading fp propaganda

nine_k 6y ago

This mixes up a few things. Immutable data means lack of aliasing problems (two pointers to a mutable cell). There are other languages that have this property, notably Fortran. It does allow many speed optimizations, in both parallel and single-thread cases. Yes, this is one of the reasons why Fortran is routinely faster than C on numeric code, and even Haskell sometimes is, too. It is theoretically proven that any algorithm which uses mutable data can be converted to use immutable data with a penalty on memory and time not exceeding O(log n). In absolute terms, such a penalty can be low, or pretty high (consider working with large bitmaps). There's no silver bullet. Functional code is often preferred due to its clarity, both humans and machines have easier time reasoning about it, and even formally proving its properties. Sometimes it is just more important than raw speed, but sometimes allows for more aggressive optimizations (rewriting by the compiler) and higher speed.

marcinzm 6y ago
>Functional code is often preferred due to its clarity, both humans and machines have easier time reasoning about it, and even formally proving its properties. Sometimes it is just more important than raw speed, but sometimes allows for more aggressive optimizations (rewriting by the compiler) and higher speed. I'm curious if that's really the case in practice. Functional code allows for clever concise implementations and clever concise implementations are notoriously hard to read. Go, for example, is often lauded for it's readability due to it's more verbose and non-clever nature. edit: To clarify, I mean readability by the above-average programmer not by a world expert who has spent 15 years becoming one with the language.

p0nce 6y ago

Where are all the FP competitors for fast programs then?

imtringued 6y ago

It's very easy to disprove this comment. Haskell is pure functional language and uses linked lists as their main list data structure. This is because it is difficult to modify individual elements in an array in a purely functional manner without copying the entire array. Meanwhile using arrays in C or Rust and changing individual elements is not only very easy, it's very fast as well. The default string implementation in Haskell is built on a linked list of characters and it performs horribly, so Haskell has multiple string implementations. The default string implementation is still often used because it is more convenient. This is an example where writing more readable code also involves making it perform worse. Rephrased: Faster code is less readable in Haskell. https://stackoverflow.com/questions/13865420/why-is-haskells-default-string-implementation-a-linked-list-of-chars https://stackoverflow.com/questions/13865420/why-is-haskells...

centimeter 6y ago
The text type everyone uses in Haskell is Data.Text, which is packed. String is not used for anything performance-sensitive.