4 ms·

Functional is generally accepted as The Best Abstraction imo

epgui 3y ago
Generally accepted… But by whom? If you mean “the software engineering community at large”, I’m not so sure… I’d say from my experience: [*] - >98% of engineers are mostly familiar with OOP - about 1% of engineers “write FP code imperatively” without knowing that they’re kind of missing the point And among the >98%: - 20% think FP is about using map/filter/reduce (not a bad start, but misses the main ideas) - 35% are openly hostile to FP for a whole variety of reasons, some better than others but none great - The rest don’t really know what FP is, and if they’d have to guess they’d say it’s when you use functions. We no longer have the same performance constraints that computer scientists had to deal with in the very early days of computing, when the theory was being written and the von neumann style of programming began to take hold. It will still take a long time (I’d wager decades) before the findings of academics are accepted in the industry. [*] These figures are all made up and are presented only as a rough way to communicate my perspective based on my experience… But again I am not particularly qualified to speak to this.
- intelVISA 3y ago
  I fear you may be right. It always felt a struggle to use FP in perf constrained contexts but with modern compute making that largely irrelevant there's really no reason to avoid indulging one's self. It is interesting though, the openly hostile subset you describe I don't really consider as working in SWE as it would be the equiv. of working in a kitchen and saying you reject using knives.
  - epgui 3y ago
    There are certainly specialized areas where FP is inappropriate, maybe even for fundamental reasons (although I am not 100% sure of this: compilers have been improving rapidly, I don't have a great sense of how much further we can theoretically/fundamentally push a c compiler versus a haskell compiler, and the variety of possible type systems adds enough complications to make my head spin). But --and maybe there's a certain skew in my work experience?-- that's probably not really relevant to the vast majority of the programming that gets done. By my estimation, most professional software engineers spend most of their time working on nonrevolutionary, fairly mundane things, like basic crud apps, web apps, microservices, frontend, backend... While a minority (I think?) work on games, codecs, embedded systems, etc. (That's not to say that performance is never a concern in these areas, of course.) But dwarfing all of the above, in numbers, are all the people who are not professional software engineers, and who are writing code as an extension of the specific work they are doing in their domain (that's all your python scripts, R scripts, ad hoc sql, lab work, etc). I'll suggest something controversial here: anything people typically think python is good for, [haskell|racket|...] is probably way better at it. That's kind of where I see the most obvious use cases. In my view anyway, it's a pretty good bet that the step-change in complexity reduction you get with FP (big scary words notwithstanding; I am speaking here of the programs' complexity) would actually have a massive positive impact on the accessibility of programming/sw-engineering to newcomers, as well as on programming/sw-engineering's already-impressive propensity for enabling cross-talk between disciplines. There's soooooooo many low hanging fruits in programming literacy.

Generally accepted… But by whom? If you mean “the software engineering community at large”, I’m not so sure… I’d say from my experience: [*] - >98% of engineers are mostly familiar with OOP - about 1% of engineers “write FP code imperatively” without knowing that they’re kind of missing the point And among the >98%: - 20% think FP is about using map/filter/reduce (not a bad start, but misses the main ideas) - 35% are openly hostile to FP for a whole variety of reasons, some better than others but none great - The rest don’t really know what FP is, and if they’d have to guess they’d say it’s when you use functions. We no longer have the same performance constraints that computer scientists had to deal with in the very early days of computing, when the theory was being written and the von neumann style of programming began to take hold. It will still take a long time (I’d wager decades) before the findings of academics are accepted in the industry. [*] These figures are all made up and are presented only as a rough way to communicate my perspective based on my experience… But again I am not particularly qualified to speak to this.

intelVISA 3y ago
I fear you may be right. It always felt a struggle to use FP in perf constrained contexts but with modern compute making that largely irrelevant there's really no reason to avoid indulging one's self. It is interesting though, the openly hostile subset you describe I don't really consider as working in SWE as it would be the equiv. of working in a kitchen and saying you reject using knives.
- epgui 3y ago
  There are certainly specialized areas where FP is inappropriate, maybe even for fundamental reasons (although I am not 100% sure of this: compilers have been improving rapidly, I don't have a great sense of how much further we can theoretically/fundamentally push a c compiler versus a haskell compiler, and the variety of possible type systems adds enough complications to make my head spin). But --and maybe there's a certain skew in my work experience?-- that's probably not really relevant to the vast majority of the programming that gets done. By my estimation, most professional software engineers spend most of their time working on nonrevolutionary, fairly mundane things, like basic crud apps, web apps, microservices, frontend, backend... While a minority (I think?) work on games, codecs, embedded systems, etc. (That's not to say that performance is never a concern in these areas, of course.) But dwarfing all of the above, in numbers, are all the people who are not professional software engineers, and who are writing code as an extension of the specific work they are doing in their domain (that's all your python scripts, R scripts, ad hoc sql, lab work, etc). I'll suggest something controversial here: anything people typically think python is good for, [haskell|racket|...] is probably way better at it. That's kind of where I see the most obvious use cases. In my view anyway, it's a pretty good bet that the step-change in complexity reduction you get with FP (big scary words notwithstanding; I am speaking here of the programs' complexity) would actually have a massive positive impact on the accessibility of programming/sw-engineering to newcomers, as well as on programming/sw-engineering's already-impressive propensity for enabling cross-talk between disciplines. There's soooooooo many low hanging fruits in programming literacy.