Honestly, this just looks like one of those lingo-heavy-but-surface-level blog posts that used to make functional programming spaces so insufferable to everyone on the outside
These things are so divorced from the reality of programming, even when they involve actual code instead of fancy lingo. Like in Scala, not a pure functional language, tutorials used to find the most convoluted higher-order functional way to do simple things.
At least in JVM land, it's pretty easy to thwart that optimization. Particularly if the condition is on a mutable yet unchanged in the loop value.
For example:
var map = new HashMap<String, String>();
map.put("foo", "bar");
for (var i : items) {
if ("bar".equals(map.get("foo")) {
doStuff(i);
}
}
Even though `map` isn't mutated, it's hard enough for the JVM to detect and the underlying `get` functions are complex enough that it'll run the `get("foo")` every time, which can be quiet expensive.
Of note, as of C#9 (and maybe prior), the dotnet runtime does this automatically whenever it is deemed safe. https://devblogs.microsoft.com/dotnet/performance-improvemen...
The same technique is applied as an optimization, when deemed safe, in all current gen c compilers (gcc, llvm, etc).
I'm very confused why neither measurements nor references to when this is done automatically in most modern languages is included in the article.
For example:
Even though `map` isn't mutated, it's hard enough for the JVM to detect and the underlying `get` functions are complex enough that it'll run the `get("foo")` every time, which can be quiet expensive.Speed was almost never the reason.