After spending years in functional-land, I find the for loop (and while loop) construct maddening; you have to maintain the state of the entire enclosing scope system in your head, whereas enumerable constructs like map and reduce close (ideally read only) over variables in scope and if you need to keep state you have to use reduce, which explicitly tracks what changes between iterations and nothing "unexpected"... In a general sense, FP enumerations are more explicit than control loops which are implicit state machines.
> After spending years in functional-land, I find the for loop (and while loop) construct maddening; you have to maintain the state of the entire enclosing scope system in your head.
This is only true if immutability is enforced. In js you see map used to mutate variables outside the scope of the map closure all the time.
const o = {}
const d = [1, 2, 3, 4]
d.map(i => o[i] = i**2)
Which is equivalent to this python.
o = {}
d = [1, 2, 3, 4]
for i in d:
o[i] = i**2
The cognitive load is the same in both. The strength of pure FP languages come from enforced immutability, but that constraint often adds cognitive load in other ways.
> constraint often adds cognitive load in other ways
In my experience (and others) those constraint only reduces cognitive load, it can increase actual performance load, and can make certain algorithms "basically impossible", but you're also never actually writing those algorithms. When was the last time you ACTUALLY used dykstra's A*? Come on, most of us are writing SAASes, APIs/backends and basic frontends here (yes, the rest of you do exist), and even for shitty O(n^2) algos, your n is probably in the 10-20 range. Your bad algorithm will not take down the server.
I think most programmers would disagree with you on this. Perhaps after enough FP experience the cognitive load that comes from the language’s constraints fade away, but I haven’t seen this in practice. FP is less commonly understood and harder for the average dev to work with.
> Come on, most of us are writing SAASes, APIs/backends and basic frontends here (yes, the rest of you do exist), and even for shitty O(n^2) algos, your n is probably in the 10-20 range. Your bad algorithm will not take down the server.
This isn’t related to the earlier point but I’ll bite. This thought process assuming “Your bad algorithm will not take down the server” is a recipe for bad engineering.
For example, we had a bulk action (1-500 records) in our API where the first implementation pulled all the data into memory and processed the data in the request. This ended up being disastrous in prod. It took down our server many times and was tricky to track down because the process would be killed when it maxed out memory.
The solution wasn’t to switch languages or anything. It was just to move the operation to our async worker queue and stream through chunks of data to avoid running out of memory. It cause a lot of headaches for devops that should have never happened.
While you’re right that there are many cases where n is not large, engineers must consider how large n can be or explicitly restrict n before pushing a bad algo to prod.
'FP is less commonly understood and harder for the average dev to work with' citation needed - if anything I'd say the opposite is true, reducing state and mutation etc makes code easier to read and reason about.
Look up any programming language popularity survey. Pure FP languages are substantially less popular, therefore less commonly understood and harder for the average dev to work with.
If FP was the norm, then you could make the same argument for OO.
I started a poll on twitter. Now, obviously there is bias since my twitter audience is mostly FP people, but keep in mind:
- almost all experienced FP people "started in OO", or at least, imperative. So if they are picking map/reduce it is out of experience with the alternative.
- the split between bootcampers/informal and CS/formal is instructive: You can see that "bootcampers", who typically have less need for a low-level mental model of what the metal is doing, find that that for/while loops are harder on the brain than map/reduce:
Pure FP languages may be less popular/common, that doesn't mean FP ideas are harder to understand. In stackoverflow's developer survey https://insights.stackoverflow.com/survey/2021 Clojure was the second most 'popular' language after Rust, and you could argue Rust draws heavily from FP styles too. Languages that are unquestionably OO or procedural, like Java and C, scored lower.
