> rather than “for” loops, it’s often easier to think in terms of the common patterns: “map”, “reduce”, “filter”.
It is. My lament there is that, at least in my experience, optimizers haven't caught up in this department. So while I invariably start with the higher-order operations, all too often the profiler subsequently informs me that I need to replace that code with a for loop.
I suspect that side effects are the culprit there: In a language without referential transparency, the optimizer's very limited in what kinds of reasoning it can make about a function. I'm not quite ready to give up side effects just yet, though. I wish I could work in a language that only allows them in functions that explicitly declare that they want to use them, though.
It is. My lament there is that, at least in my experience, optimizers haven't caught up in this department. So while I invariably start with the higher-order operations, all too often the profiler subsequently informs me that I need to replace that code with a for loop.
I suspect that side effects are the culprit there: In a language without referential transparency, the optimizer's very limited in what kinds of reasoning it can make about a function. I'm not quite ready to give up side effects just yet, though. I wish I could work in a language that only allows them in functions that explicitly declare that they want to use them, though.