The thing with functional languages is, you can find a lot of articles and videos extolling their virtues. But they sound like the same promises every other language makes to try to get you to use them. So nobody really believes it. And on top of that you have extra things to learn like expressions-instead-of-statements, union types, immutability (this one is the same as "defensive copying" in OO, except it is the expected norm and there is language syntax sugar). So the idea does not make it through many devs built-in BS filter. I think it really takes someone you trust to tell you: "For real, there is something special about this. You should give it an honest try." For example, being told about type inference holds no comparison to typing out what you figure will be pseudocode, and realizing the compiler already knows the types. Or after a year, you come back to some code and do an epic refactor, but since you used pure functions it turns out to be easy and not risky. Southern saying: "Better felt than tell't."
So getting people to try it (like a real try, not "I gave up when it complained about a missing else.") is most of the battle. I don't know what I could say any differently from all those other videos and articles which talk it up. Just try it people, really try it. It's okay if you ultimately "get it" but still like objects or procedures better -- it's still a useful perspective to learn.
What I think is really the first enemy of learning (anything, not just functional programming) is herd mentality. When you work at a place where the most people don't view learning new things as important, your learning muscle gets atrophied. When I got an equivalent of a scoff writing something in Ocaml, I faded away.
A specific enemy to learning a functional programming is math. The author of F# for Fun and Profit stated this very nicely, but functional languages need to ease down on math. Stop campaigning lambda calculus. It's not helping, because it attracts snobs who will keep putting functional programming on higher and higher pedestal ("Oh, really, you don't know what a monad is?") and scare away new developers.
Re:math-focus. Maybe I'll change my mind one day, but this is exactly why I could not bring myself to deploy Haskell code. Even if I could be super productive with it, bringing on fresh devs seems drastically harder than something like F# because of the intertwining of category theory. I would never say this out loud, but since it is just you and me 😉, I have a theory that Haskell is more object-oriented than most OO languages. Because you kinda have to derive from the category theory objects to make canonical use of it. Whereas something like F# or OCaml or Elm, you can just pretend you are doing procedural programming + expressions + immutability + pure functions to get started and be productive. Then later notice that a lot of types use the same functions: map, bind/andThen, etc. So if you understand them once, you understand them everywhere. Then later you discover these operations are not just some dude's arbitrary contrivance, but based on provable math. mind blown. It is a great learning story IMO.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have sortof been doing so, though not necessary in the context of F#.
The thing with functional languages is, you can find a lot of articles and videos extolling their virtues. But they sound like the same promises every other language makes to try to get you to use them. So nobody really believes it. And on top of that you have extra things to learn like expressions-instead-of-statements, union types, immutability (this one is the same as "defensive copying" in OO, except it is the expected norm and there is language syntax sugar). So the idea does not make it through many devs built-in BS filter. I think it really takes someone you trust to tell you: "For real, there is something special about this. You should give it an honest try." For example, being told about type inference holds no comparison to typing out what you figure will be pseudocode, and realizing the compiler already knows the types. Or after a year, you come back to some code and do an epic refactor, but since you used pure functions it turns out to be easy and not risky. Southern saying: "Better felt than tell't."
So getting people to try it (like a real try, not "I gave up when it complained about a missing
else.") is most of the battle. I don't know what I could say any differently from all those other videos and articles which talk it up. Just try it people, really try it. It's okay if you ultimately "get it" but still like objects or procedures better -- it's still a useful perspective to learn.What I think is really the first enemy of learning (anything, not just functional programming) is herd mentality. When you work at a place where the most people don't view learning new things as important, your learning muscle gets atrophied. When I got an equivalent of a scoff writing something in Ocaml, I faded away.
A specific enemy to learning a functional programming is math. The author of F# for Fun and Profit stated this very nicely, but functional languages need to ease down on math. Stop campaigning lambda calculus. It's not helping, because it attracts snobs who will keep putting functional programming on higher and higher pedestal ("Oh, really, you don't know what a monad is?") and scare away new developers.
Yeah, I completely agree.
Re:math-focus. Maybe I'll change my mind one day, but this is exactly why I could not bring myself to deploy Haskell code. Even if I could be super productive with it, bringing on fresh devs seems drastically harder than something like F# because of the intertwining of category theory. I would never say this out loud, but since it is just you and me 😉, I have a theory that Haskell is more object-oriented than most OO languages. Because you kinda have to derive from the category theory objects to make canonical use of it. Whereas something like F# or OCaml or Elm, you can just pretend you are doing procedural programming + expressions + immutability + pure functions to get started and be productive. Then later notice that a lot of types use the same functions:
map,bind/andThen, etc. So if you understand them once, you understand them everywhere. Then later you discover these operations are not just some dude's arbitrary contrivance, but based on provable math. mind blown. It is a great learning story IMO.