3 ms·

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

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.

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.