3 ms·

> I think within five years or so, functional-first programming will be the norm. I highly, highly doubt this.

by xyzzy4 10y ago

youdontknowtho 10y ago
The guy that writes Mechanical Sympathy, Martin Thompson, has said that people who think pure functional programming are the future are missing the point that hardware favors the imperative model. He's worth a listen to. Many talks on YouTube.
- Pica_soO 10y ago
  Im hearing that for the first time, could you elaborate?
  - mping 10y ago
    I'm guessing it is easier to optimize via imperative way than functional. Although you can optimize functional libs up to a point, I say that people with enough time and dedication will probably optimize better with imperative paradigm. OTOH not a lot of projects require uber optimizations.
  - pjmlp 10y ago
    The issue is that imperative algorithms and data structures are easier to optimize for hardware regarding cache sizes, memory access patterns and memory reuse. Whereas this is also possible in FP languages, but since they tend to abstract the hardware, it requires support from "clever" compilers. I don't fully agree with him, given the previous experience with the Connection Machine and *Lisp, but as usual in computing, unless one doesn't implement something and prove it with benchmarks, it doesn't happen. https://en.wikipedia.org/wiki/Connection_Machine https://en.wikipedia.org/wiki/Connection_Machine
    - youdontknowtho 10y ago
      Actually, that was one of his major points in the lecture that I referenced. Basically, you should start with measurements and go from there. He said that he personally uses FP quite a bit, so he wasn't a hater per se...except for FP fan boys. He did go on about that quite a bit. The main thing that he stressed about data structures was that memory layout matters in that hardware has a lot of built in intelligence for accelerating memory access patterns that it can discern. The way that immutable data structures are created, updated, and destroyed don't produce a suitably detectable memory access pattern, apparently. His explanation was detailed and is worth watching. That being said he wasn't proposing "share state for all". He was mainly proposing the scientific method.
- Horusiath 10y ago
  He is writing that statement from a perspective of engineer of high performance / low latency systems. If one uses that argument while developing N-tier "enterprise" application with huge ORM, DI and web framework on top of it... that's missing a point.
- T-A 10y ago
  A common argument for functional programming is that it's inherently better suited to parallel hardware [1]. So if you buy this, and agree that future hardware is likely to emphasize more cores over faster ones, you have an argument for functional programming being the way of the future. Of course, this argument has been made at least since the 80s... [1] http://programmers.stackexchange.com/questions/293851/what-is-it-about-functional-programming-that-makes-it-inherently-adapted-to-para http://programmers.stackexchange.com/questions/293851/what-i...
  - youdontknowtho 10y ago
    Like I said, his talk is worth watching. he makes some detailed arguments to back his case. He spends a large part of the talk going over concurrency myths that he's encountered over the years. And even with all of that, his main point was that you should use the scientific method and make measurements and adjust your approach based on those measurements. It's on here somewhere: https://www.infoq.com/author/Martin-Thompson https://www.infoq.com/author/Martin-Thompson

> I think within five years or so, functional-first programming will be the norm. I highly, highly doubt this.

by xyzzy4 10y ago

> I think within five years or so, functional-first programming will be the norm. I highly, highly doubt this.

The guy that writes Mechanical Sympathy, Martin Thompson, has said that people who think pure functional programming are the future are missing the point that hardware favors the imperative model. He's worth a listen to. Many talks on YouTube.

Pica_soO 10y ago
Im hearing that for the first time, could you elaborate?
- mping 10y ago
  I'm guessing it is easier to optimize via imperative way than functional. Although you can optimize functional libs up to a point, I say that people with enough time and dedication will probably optimize better with imperative paradigm. OTOH not a lot of projects require uber optimizations.
- pjmlp 10y ago
  The issue is that imperative algorithms and data structures are easier to optimize for hardware regarding cache sizes, memory access patterns and memory reuse. Whereas this is also possible in FP languages, but since they tend to abstract the hardware, it requires support from "clever" compilers. I don't fully agree with him, given the previous experience with the Connection Machine and *Lisp, but as usual in computing, unless one doesn't implement something and prove it with benchmarks, it doesn't happen. https://en.wikipedia.org/wiki/Connection_Machine https://en.wikipedia.org/wiki/Connection_Machine
  - youdontknowtho 10y ago
    Actually, that was one of his major points in the lecture that I referenced. Basically, you should start with measurements and go from there. He said that he personally uses FP quite a bit, so he wasn't a hater per se...except for FP fan boys. He did go on about that quite a bit. The main thing that he stressed about data structures was that memory layout matters in that hardware has a lot of built in intelligence for accelerating memory access patterns that it can discern. The way that immutable data structures are created, updated, and destroyed don't produce a suitably detectable memory access pattern, apparently. His explanation was detailed and is worth watching. That being said he wasn't proposing "share state for all". He was mainly proposing the scientific method.
Horusiath 10y ago
He is writing that statement from a perspective of engineer of high performance / low latency systems. If one uses that argument while developing N-tier "enterprise" application with huge ORM, DI and web framework on top of it... that's missing a point.
T-A 10y ago
A common argument for functional programming is that it's inherently better suited to parallel hardware [1]. So if you buy this, and agree that future hardware is likely to emphasize more cores over faster ones, you have an argument for functional programming being the way of the future. Of course, this argument has been made at least since the 80s... [1] http://programmers.stackexchange.com/questions/293851/what-is-it-about-functional-programming-that-makes-it-inherently-adapted-to-para http://programmers.stackexchange.com/questions/293851/what-i...
- youdontknowtho 10y ago
  Like I said, his talk is worth watching. he makes some detailed arguments to back his case. He spends a large part of the talk going over concurrency myths that he's encountered over the years. And even with all of that, his main point was that you should use the scientific method and make measurements and adjust your approach based on those measurements. It's on here somewhere: https://www.infoq.com/author/Martin-Thompson https://www.infoq.com/author/Martin-Thompson