4 ms·

“Most 'developers' don't understand functional programming concepts, and can't even write very good imperative code in C#. So what hope have they got of writing

“Most 'developers' don't understand functional programming concepts, and can't even write very good imperative code in C#. So what hope have they got of writing good functional code in F#?” i hope 11 years later we have a different attitude

umanwizard 6y ago
What's wrong with that attitude and what do you think should be better by now?
- rendall 6y ago
  I can't speak for melling but as for me, that attitude struck me as dismissive not only of the capacity of the average developer to understand fp, but a bit of fp itself as too hard. 11 years later, fp concepts are more generally understood, accepted, and used; and the attitude has shown to be incorrect. fp is not that hard. It is, in fact, easier than OO
  - gameswithgo 6y ago
    Well, SOME ideas have proven easy to understand. The use of higher order functions like Filter/Map etc are definitely widespread now and have proven their usefulness. The idea of keeping functions pure, when you can without making a mess of things, has pretty wide agreement. The use of Option types instead of Null is getting to the point of being widespread (C# 9 sorta does it, Zig kinda does it, people love it in Rust and F#) But other things like, passing partially applied functions to other functions, that to me is still really hard to reason about, especially with type inference on those function signatures. Immutable data structures, while nice to reason about sometimes have huge performance downsides. And computers aren't really getting faster in ways that help that much anymore.
    - akra 6y ago
      "partially applied functions to other functions" - In C# you do this anyway via Fluent interfaces and/or lambda Func<_> arguments. The only difference is in F# any function can be made into a fluent style pipeline (|> operator) due to this partial application whereas in C# the function has to be built specifically for it. Partial application for me is one of the reasons F# code tends to be nicer than C#/Java code there's less need for things like DI containers, and other big frameworks each with their own learning curve and corner cases. It feels more like I'm coding in a static version of JS/Python once you get used to it vs C#/Java which have a lot of ceremony - expect that type inference you mention means those partially completed functions are much less likely to be used wrong.
  - mrkeen 6y ago
    > that attitude struck me as dismissive not only of the capacity of the average developer to understand fp, but a bit of fp itself as too hard. It's a self-inflicted criticism. It's non-fpers saying that fp is too hard, not fpers.
mrkeen 6y ago
Me in 2010: "Functional programming is great because you can write code that always gives the same output for the same input, making it super easy to test, debug and share. The downside is you need to put down those for-loops and start thinking in terms of map and reduce instead." Programmers in 2020: "Yeah some of the people on the team know how to use flatMap."

umanwizard 6y ago

What's wrong with that attitude and what do you think should be better by now?

rendall 6y ago
I can't speak for melling but as for me, that attitude struck me as dismissive not only of the capacity of the average developer to understand fp, but a bit of fp itself as too hard. 11 years later, fp concepts are more generally understood, accepted, and used; and the attitude has shown to be incorrect. fp is not that hard. It is, in fact, easier than OO
- gameswithgo 6y ago
  Well, SOME ideas have proven easy to understand. The use of higher order functions like Filter/Map etc are definitely widespread now and have proven their usefulness. The idea of keeping functions pure, when you can without making a mess of things, has pretty wide agreement. The use of Option types instead of Null is getting to the point of being widespread (C# 9 sorta does it, Zig kinda does it, people love it in Rust and F#) But other things like, passing partially applied functions to other functions, that to me is still really hard to reason about, especially with type inference on those function signatures. Immutable data structures, while nice to reason about sometimes have huge performance downsides. And computers aren't really getting faster in ways that help that much anymore.
  - akra 6y ago
    "partially applied functions to other functions" - In C# you do this anyway via Fluent interfaces and/or lambda Func<_> arguments. The only difference is in F# any function can be made into a fluent style pipeline (|> operator) due to this partial application whereas in C# the function has to be built specifically for it. Partial application for me is one of the reasons F# code tends to be nicer than C#/Java code there's less need for things like DI containers, and other big frameworks each with their own learning curve and corner cases. It feels more like I'm coding in a static version of JS/Python once you get used to it vs C#/Java which have a lot of ceremony - expect that type inference you mention means those partially completed functions are much less likely to be used wrong.
- mrkeen 6y ago
  > that attitude struck me as dismissive not only of the capacity of the average developer to understand fp, but a bit of fp itself as too hard. It's a self-inflicted criticism. It's non-fpers saying that fp is too hard, not fpers.

mrkeen 6y ago

Me in 2010: "Functional programming is great because you can write code that always gives the same output for the same input, making it super easy to test, debug and share. The downside is you need to put down those for-loops and start thinking in terms of map and reduce instead." Programmers in 2020: "Yeah some of the people on the team know how to use flatMap."