4 ms·

1. Older paradigms have been reinforced by many predecessors, creating lindy effect. 2. Being a relatively new paradigm, less people understand where, when, ho

by valand 7y ago

1. Older paradigms have been reinforced by many predecessors, creating lindy effect. 2. Being a relatively new paradigm, less people understand where, when, how, and why FP fits. There is a lack of effective education over FP. 3. Having some radical jargons (e.g. HOF, recursion > looping) , FP brings fear of change. Especially, recursion > looping can only be applied to languages with gc, preferably those with tail call optimization. 4. FP's more universal virtues (immutability, pure functions, type system, no side effect) are not advertised enough compared to other virtues (recursion, hof).

fulafel 7y ago
I think your 3/4 are true for some people, maybe for those who were taught academically flavoured FP in a computer science program, but on the other hand when I web search for "why functional programming", the articles bring up immutability and side effects first and rarely mention recursion or higher order functions. Also, can't resist nitpicking about tail call optimization: clang/llvm and gcc implement it in a non-gc language (C), but meanwhile some FP language implementations lack it, at least Clojure does. So while there's more demand for that feature in the FP world and some FP languages like Scheme require implementations to perform this optimization, it's conceptually somewhat orthogonal to FP or GC.
- valand 7y ago
  I didn't mean to say immutabilty and no-side-effects are advertised less. It's just not enough of them are effective. Those concepts helped me avoid a lot of headaches without knowing that those are concepts of FP. Then there was a day where I just realized, "Oh, this is FP" I guess people need to be educated, or experience themselves, the concepts, before hearing the word "FP" which mean less to them. The examples provided in the internet needs to be more ambituous than mere chains of functions. They need to be "remaking rsync with minimum IFs" or "large scale React App without a single getDerivedState"

by valand 7y ago

fulafel 7y ago

I think your 3/4 are true for some people, maybe for those who were taught academically flavoured FP in a computer science program, but on the other hand when I web search for "why functional programming", the articles bring up immutability and side effects first and rarely mention recursion or higher order functions. Also, can't resist nitpicking about tail call optimization: clang/llvm and gcc implement it in a non-gc language (C), but meanwhile some FP language implementations lack it, at least Clojure does. So while there's more demand for that feature in the FP world and some FP languages like Scheme require implementations to perform this optimization, it's conceptually somewhat orthogonal to FP or GC.

valand 7y ago
I didn't mean to say immutabilty and no-side-effects are advertised less. It's just not enough of them are effective. Those concepts helped me avoid a lot of headaches without knowing that those are concepts of FP. Then there was a day where I just realized, "Oh, this is FP" I guess people need to be educated, or experience themselves, the concepts, before hearing the word "FP" which mean less to them. The examples provided in the internet needs to be more ambituous than mere chains of functions. They need to be "remaking rsync with minimum IFs" or "large scale React App without a single getDerivedState"