4 ms·

Alright, here's the hot take: The assignment is for any developer without basic knowledge of FP beyond .map and .filter to complete their intermediate-level pr

Alright, here's the hot take: The assignment is for any developer without basic knowledge of FP beyond .map and .filter to complete their intermediate-level programming education. All problem domains that involve declarative programming, such as configuration (Terraform, Kubernetes, Nix, many build systems), dynamic HTML, relational databases, and pretty much anything that is manipulating data in a pipeline fits functional programming like a glove and is hard to get right in a strictly traditionally imperative fashion. As an industry we should stop pretending FP isn't a necessary part of a professional programmer's education and that we can solve the problem by coming up with the umpteenth "we promise it's not FP" abstraction with its own take on fooling developers into writing functional code through an imperative-looking layer full of foot guns that subtly break imperative developer expectations, like React.

verall 5y ago
I think it's a super hot take because the real world has demonstrated (over and over again) that a huge portion of professional software developers have no interest in learning functional paradigms just to write some config files. Just like a huge portion of professional software developers have no interest in learning RTL or digital logic just to program an FPGA. HLS is a massively complex system to solve this problem. People will also build massively complex systems to solve the problem of "No FP here, please".
- klekticist 5y ago
  I agree with your point here, though imo it's worth drawing a distinction between the FP concepts the language designers / implementors must understand and the FP concepts the language users must understand. Ideally languages prevent bug classes like null deref, use after free while still being familiar enough for most programmers to use. It's analogous to the spectrum of SQL knowledge folks have. For instance knowing what a group by does vs how a group by reshuffles data on a single node / across nodes. Ideally the language design hides the hard details. A very tall order admittedly.
- mixedCase 5y ago
  That'd be fine if it was just config files, but that's not the problem now isn't it?. It's an enormous amount of problem domains that FP handles trivially and is a complete pain to manage imperatively. We've had entire groups of people coming up with ridiculous ideas like replacing relational databases with key-value stores for relational data just because they find SQL "icky" because it fits a mental model they never developed (syntax issues with SQL aside) and it isn't until they're hand rolling data aggregation that they realize the mess they got themselves into. Which is why I stand by what I said: this knowledge is not optional, and engineers not willing to learn them are going to be stuck with sub-optimal tools, dragging the whole industry down with them. While I can't be confident this is the definitive solution, I believe that the best way to move forward is to start treating basic FP (purity, data transformation pipelines, immutability, favoring data structures over code) as a baseline that everyone needs to know to work as a developer, and stop treating it as if it is on a superior level of difficulty compared to learning whatever bullshit combination of half-templated server side rendering, 4D DOMs and incantations needed to upgrade Webpack we need to know to be "up to speed" nowadays.
- staticassertion 5y ago
  > (over and over again) Eh. I'm not saying one way or the other that FP is good or bad, but the software industry is incredibly young and changes a lot. Even in a relatively short period - 10 years, let's say - things are pretty difference. 20 years, still a short time, and things are radically different. And on top of that, it is still the case that a lot of stuff takes a long time to get adopted. It's hard to build and popularize a programming language, regardless of how good or bad that language is, because they tend to lack interoperability with other languages if they're very different, which is usually a requirement if they want to be considered worth looking at. So I'd just as easily buy that people haven't used a lot of FP due to inertia, a lack of the right external inventives, etc, and not by any virtue of the paradigm.
Xavdidtheshadow 5y ago
Do you have resources to this end that you'd recommend?
- mixedCase 5y ago
  The easiest hands-on approach I know of is to go through the Elm tutorial and build a simple CRUD app. The rest should flow from there. After that, https://fsharpforfunandprofit.com/series/why-use-fsharp/ https://fsharpforfunandprofit.com/series/why-use-fsharp/ and pretty much anything made by Scott Wlaschin is very accessible, and to the point.
  - ModernMech 5y ago
    Missed opportunity: fsharpforfunandfunds
throwaway894345 5y ago
I mean, maybe. I’ve dabbled in FP a fair amount, but I was never convinced that it’s categorically better for developing software than imperative programming. Certainly it has its strengths and I enjoy it. But ultimately it doesn’t matter because the reality is that imperative languages dominate the industry, and I doubt that will change for the next decade if only for inertia.
8n4vidtmkvmk 5y ago
so what then is the friendliest functional programming language for those of us with lots of... non-fp experience but very little fp exposure?
- tasuki 5y ago
  Imo, Elm is the friendliest pure functional language. It's a frontend language though. I'm a backend developer by trade and Elm made me fall in love with frontend development, which I've rather hated before.
- catlifeonmars 5y ago
  The ML family is the most reasonable IMO. Languages such as OCAML and ReasonML feel like they’re designed to solve real world problems rather than adhering to type manipulation pedantry.
- xmcqdpt2 5y ago
  "Standard" Scala (i.e. without the fancy monadic libraries like cats or zio) and Rust are both mixed paradigm languages with good support for many FP constructs. In practice you can write imperative code using either of them but the focus on immutable data structures, and (in Rust more than Scala) functional error handling means that many manipulations are easier to do with FP constructs, so they appear quite naturally (Option, Result/Try, iterator maps etc.) As a bonus IME they are very similar in many respects so experience in one translates well to the other.

verall 5y ago

I think it's a super hot take because the real world has demonstrated (over and over again) that a huge portion of professional software developers have no interest in learning functional paradigms just to write some config files. Just like a huge portion of professional software developers have no interest in learning RTL or digital logic just to program an FPGA. HLS is a massively complex system to solve this problem. People will also build massively complex systems to solve the problem of "No FP here, please".

klekticist 5y ago
I agree with your point here, though imo it's worth drawing a distinction between the FP concepts the language designers / implementors must understand and the FP concepts the language users must understand. Ideally languages prevent bug classes like null deref, use after free while still being familiar enough for most programmers to use. It's analogous to the spectrum of SQL knowledge folks have. For instance knowing what a group by does vs how a group by reshuffles data on a single node / across nodes. Ideally the language design hides the hard details. A very tall order admittedly.
mixedCase 5y ago
That'd be fine if it was just config files, but that's not the problem now isn't it?. It's an enormous amount of problem domains that FP handles trivially and is a complete pain to manage imperatively. We've had entire groups of people coming up with ridiculous ideas like replacing relational databases with key-value stores for relational data just because they find SQL "icky" because it fits a mental model they never developed (syntax issues with SQL aside) and it isn't until they're hand rolling data aggregation that they realize the mess they got themselves into. Which is why I stand by what I said: this knowledge is not optional, and engineers not willing to learn them are going to be stuck with sub-optimal tools, dragging the whole industry down with them. While I can't be confident this is the definitive solution, I believe that the best way to move forward is to start treating basic FP (purity, data transformation pipelines, immutability, favoring data structures over code) as a baseline that everyone needs to know to work as a developer, and stop treating it as if it is on a superior level of difficulty compared to learning whatever bullshit combination of half-templated server side rendering, 4D DOMs and incantations needed to upgrade Webpack we need to know to be "up to speed" nowadays.
staticassertion 5y ago
> (over and over again) Eh. I'm not saying one way or the other that FP is good or bad, but the software industry is incredibly young and changes a lot. Even in a relatively short period - 10 years, let's say - things are pretty difference. 20 years, still a short time, and things are radically different. And on top of that, it is still the case that a lot of stuff takes a long time to get adopted. It's hard to build and popularize a programming language, regardless of how good or bad that language is, because they tend to lack interoperability with other languages if they're very different, which is usually a requirement if they want to be considered worth looking at. So I'd just as easily buy that people haven't used a lot of FP due to inertia, a lack of the right external inventives, etc, and not by any virtue of the paradigm.

Xavdidtheshadow 5y ago

Do you have resources to this end that you'd recommend?

mixedCase 5y ago
The easiest hands-on approach I know of is to go through the Elm tutorial and build a simple CRUD app. The rest should flow from there. After that, https://fsharpforfunandprofit.com/series/why-use-fsharp/ https://fsharpforfunandprofit.com/series/why-use-fsharp/ and pretty much anything made by Scott Wlaschin is very accessible, and to the point.
- ModernMech 5y ago
  Missed opportunity: fsharpforfunandfunds

throwaway894345 5y ago

I mean, maybe. I’ve dabbled in FP a fair amount, but I was never convinced that it’s categorically better for developing software than imperative programming. Certainly it has its strengths and I enjoy it. But ultimately it doesn’t matter because the reality is that imperative languages dominate the industry, and I doubt that will change for the next decade if only for inertia.

8n4vidtmkvmk 5y ago

so what then is the friendliest functional programming language for those of us with lots of... non-fp experience but very little fp exposure?

tasuki 5y ago
Imo, Elm is the friendliest pure functional language. It's a frontend language though. I'm a backend developer by trade and Elm made me fall in love with frontend development, which I've rather hated before.
catlifeonmars 5y ago
The ML family is the most reasonable IMO. Languages such as OCAML and ReasonML feel like they’re designed to solve real world problems rather than adhering to type manipulation pedantry.
xmcqdpt2 5y ago
"Standard" Scala (i.e. without the fancy monadic libraries like cats or zio) and Rust are both mixed paradigm languages with good support for many FP constructs. In practice you can write imperative code using either of them but the focus on immutable data structures, and (in Rust more than Scala) functional error handling means that many manipulations are easier to do with FP constructs, so they appear quite naturally (Option, Result/Try, iterator maps etc.) As a bonus IME they are very similar in many respects so experience in one translates well to the other.