And i think the reason for things like map and filter, versus a traditional for loop, might be that behind the scenes optimizations can be made without affecting the operation of the function.
As time marches on, a for loop will always be as optimised as it will be. It loops N times, and it does this thing. A map, however, can be tweaked in the parser itself, as long as the W3C spec is met. We don’t need to know how it does it’s thing, it does and that’s enough.
But over time, if optimizations were needed to HOF like these, they could be introduced with minimal disruption. In theory.
I’ll admit that I’m biased because I am specifically a ‘high performance’ software engineer, but I think that a little bit of keeping performance best practices in mind can go a long way. I also honestly believe that, used correctly, my Two Rules for Generally Not Slow Code™ tend to produce simpler, cleaner, and faster code.
You can, like all coding guidelines, take it too far, but hey, we all know that absolute rules are always a bad idea
I just would say that there have been times when I have explicitly broken your two rules because it made for more readable code and I determined that the amount of data could never get remotely close enough to be big enough to have any meaningful affect on performance. I put a high value on readability and maintainability, so to me that was a good tradeoff. #ymmv
It’s very good, though note it is just an old[ish] man opining on things he thinks are good/bad. He was a very smart and very likeable old man and IMO it’s a brilliant talk, but nevertheless.
Quote is more like: “how do you make programs go faster? [Based on experience of designing & implementing Erlang] If you get a better algorithm and don’t change programming language, you might get about a six times speedup. If you change programming language you can go a lot faster – for example Prolog to C was about a fifty times speedup. But these aren’t the big performance gains. These come from doing sod all and waiting…we get about a factor of a thousand every ten years. So if you want you program to run a million times faster, you just do nothing for twenty years.”
