5 ms·

The author does have a point. Another issue is that the problems FP solves are problems that I think many developers genuinely don't have. Or when they do have

The author does have a point. Another issue is that the problems FP solves are problems that I think many developers genuinely don't have. Or when they do have them, they occur in very specific ways that can easily be handled with an 80% solution bolted onto an existing imperative-first language. Node, LINQ and Numpy all come to mind. These have the advantage of confining the weirdness to one spot, which makes it easier for users to accept them because they don't feel trapped the way they might in a language like Haskell or Racket. Meanwhile, FP does introduce some of its own problems, and I think many of my fellow FP fans are too quick to downplay them. Performance is one. It might be solvable by compilers, but for those of us who are not likely to spend much time hacking on the compiler for our language of choice that's a small consolation. The end result being, it's still the case that my adventures in functional programming (which are generally done using a multiparadigm language like F# or Scala) will go something like this more often than I care to admit: 1. Implement imperative solution. 2. Feel guilty, go back and replace it with functional one. 3. Find performance problem. Dig out optimizer. 4. Optimizer points to code from step 2. 5. Revert back to version from step 1.

pcwalton 11y ago
I dunno. In Rust we've found that the functional idioms are frequently faster than the imperative ones. That's because it's easier for the compiler to remove bounds checks with functional programming styles. Also, we eliminated the overheads usually assocated with FP (closure construction, indirect branches).
- dikaiosune 11y ago
  I suspect that this is an area where Rust shines in a way I haven't seen described for other functional languages, so I don't know if it's as relevant to people working in those other languages, but I haven't really written anything performance sensitive and functionally-styled except in Rust. Anecdotally, I have found a couple of times that I needed to manually implement a beautifully simple map/filter/fold call sequence in Rust because it was in a hot loop and just wasn't performing as well as a dynamic programming version that I wrote in the course of benchmarking. I've also found that plenty of times the functional style beat my hand-rolled code, which is an absolutely fantastic result, but I don't think that the compiler is yet sufficiently intelligent to replace all of my hand-rolled loops :).
marcosdumay 11y ago
> FP solves are problems that I think many developers genuinely don't have I've felt this way [1] about Python, well, more than once. I'm feeling the same way by learning Haskell. Except that with Python I learn the good parts fast, and then it's back to normal life. With Haskell things keep getting better and better... It's in part because Haskell is harder, but the improvements are also much larger. [1] https://xkcd.com/353/ https://xkcd.com/353/
hcarvalhoalves 11y ago
> Another issue is that the problems FP solves are problems that I think many developers genuinely don't have. Here's the one billion dollar question. Which is harder? 1) Correct code 2) Fast code
- contravariant 11y ago
  Neither of those two are particularly difficult.
- nostrademons 11y ago
  You forgot a couple options: 3) Available code 4) Familiar code The history of the software industry has basically been 40 years of customers choosing code that exists, solves their problem right now, and doesn't make them think too hard about how to use it. They choose this over correct code (hence, Microsoft) and over fast code (hence, Python/Ruby/Javascript/PHP). FP actually helps you write both fast and correct code. The problem is that it requires a good deal more planning up-front and more effort to change things when requirements change. This has usually been a non-starter with the majority of customers: they want software that does what they need it to do, right now, and will continue to do what they need it to if they change their mind. If it screws up occasionally or makes people wait, that's okay, it's still faster & more accurate than a human is.
- pklausler 11y ago
  Slow is way faster than wrong.
- bunderbunder 11y ago
  I think you're also trying to imply that it's inherently more difficult to write correct code in imperative style. TBH, I'm not convinced this is the case for most developers. You can't just look at what fans of functional programming say. That's a self-selected group, so you're dealing with an observation that may be biased for any number of reasons. The closest I've come to seeing an objective comparison was when I was TAing intro CS classes in undergrad, so I had the opportunity to see the same people have to use both. In that case, it seemed to me like folks had difficulty writing correct code regardless of paradigm. The difference was, with the imperative language you'd see a lot of mostly-working code with a few bugs. With the functional one you'd see a lot of failing to even get off the ground. If we assume, for the sake of argument, that that's a reasonable characterization of what the typical person experiences when they try FP, is it really any surprise that it's not more popular? Nobody wants to work in a language that makes them feel frustrated and/or stupid. And you're not sweetening the deal at all when you insult them by implying that their code is inherently buggy because of the language they use.
weavejester 11y ago
I tend to expect performance to be a problem with FP, but I don't tend find it to be the case in practice. Immutable data structures are slower than mutable data structures, but typically only by a fixed order of magnitude. FP also tends to make use of more functions and closures, but those are usually quite performant. I'm a little curious as to why you find FP performance problematic. I guess you must be trying to solve some pretty CPU-intensive problems?

pcwalton 11y ago

I dunno. In Rust we've found that the functional idioms are frequently faster than the imperative ones. That's because it's easier for the compiler to remove bounds checks with functional programming styles. Also, we eliminated the overheads usually assocated with FP (closure construction, indirect branches).

dikaiosune 11y ago
I suspect that this is an area where Rust shines in a way I haven't seen described for other functional languages, so I don't know if it's as relevant to people working in those other languages, but I haven't really written anything performance sensitive and functionally-styled except in Rust. Anecdotally, I have found a couple of times that I needed to manually implement a beautifully simple map/filter/fold call sequence in Rust because it was in a hot loop and just wasn't performing as well as a dynamic programming version that I wrote in the course of benchmarking. I've also found that plenty of times the functional style beat my hand-rolled code, which is an absolutely fantastic result, but I don't think that the compiler is yet sufficiently intelligent to replace all of my hand-rolled loops :).

marcosdumay 11y ago

> FP solves are problems that I think many developers genuinely don't have I've felt this way [1] about Python, well, more than once. I'm feeling the same way by learning Haskell. Except that with Python I learn the good parts fast, and then it's back to normal life. With Haskell things keep getting better and better... It's in part because Haskell is harder, but the improvements are also much larger. [1] https://xkcd.com/353/ https://xkcd.com/353/

hcarvalhoalves 11y ago

> Another issue is that the problems FP solves are problems that I think many developers genuinely don't have. Here's the one billion dollar question. Which is harder? 1) Correct code 2) Fast code

contravariant 11y ago
Neither of those two are particularly difficult.
nostrademons 11y ago
You forgot a couple options: 3) Available code 4) Familiar code The history of the software industry has basically been 40 years of customers choosing code that exists, solves their problem right now, and doesn't make them think too hard about how to use it. They choose this over correct code (hence, Microsoft) and over fast code (hence, Python/Ruby/Javascript/PHP). FP actually helps you write both fast and correct code. The problem is that it requires a good deal more planning up-front and more effort to change things when requirements change. This has usually been a non-starter with the majority of customers: they want software that does what they need it to do, right now, and will continue to do what they need it to if they change their mind. If it screws up occasionally or makes people wait, that's okay, it's still faster & more accurate than a human is.
pklausler 11y ago
Slow is way faster than wrong.
bunderbunder 11y ago
I think you're also trying to imply that it's inherently more difficult to write correct code in imperative style. TBH, I'm not convinced this is the case for most developers. You can't just look at what fans of functional programming say. That's a self-selected group, so you're dealing with an observation that may be biased for any number of reasons. The closest I've come to seeing an objective comparison was when I was TAing intro CS classes in undergrad, so I had the opportunity to see the same people have to use both. In that case, it seemed to me like folks had difficulty writing correct code regardless of paradigm. The difference was, with the imperative language you'd see a lot of mostly-working code with a few bugs. With the functional one you'd see a lot of failing to even get off the ground. If we assume, for the sake of argument, that that's a reasonable characterization of what the typical person experiences when they try FP, is it really any surprise that it's not more popular? Nobody wants to work in a language that makes them feel frustrated and/or stupid. And you're not sweetening the deal at all when you insult them by implying that their code is inherently buggy because of the language they use.

weavejester 11y ago

I tend to expect performance to be a problem with FP, but I don't tend find it to be the case in practice. Immutable data structures are slower than mutable data structures, but typically only by a fixed order of magnitude. FP also tends to make use of more functions and closures, but those are usually quite performant. I'm a little curious as to why you find FP performance problematic. I guess you must be trying to solve some pretty CPU-intensive problems?