I quite like the answer Normand gives in that video, The one-liner thing points to an optimal efficiency of expression. I take your point that it doesn't quite get to the heart of the matter, but I think he gets there as he expands on his answer, particularly when he gets to the part on being able to interrogate data with a set of questions and abstract the concept of questions away from the datasets. That might be the most useful and enduring feature of list comprehensions.

I would argue that it should be possible to see that

const r = xs.map(foo);

const r = [];
for (var i = 0; i< xs.length; i++) {
   r[i] = foo(xs[i]);
}

and, if we were talking about C, I could probs implement such a thing in assembler as well, but why on earth would I choose to go such pains?

the higher level thing like xs.map might be more optimized well by intrinsics in the compiler or mappings to native functions, such that doing it yourself in more verbose code is actually slower. It highly depends on the runtime / implementation and what is more performant today could change tomorrow

sure

all I'm saying is: the people who are saying "I'll do it in a for-loop because I know that's faster in gcc 9.8.3-ubuntu2" or whatever are probably not the same crowd that's saying "I'll do that in a for-loop because I have no idea what map is"

And yes, sometimes assembly is (still) the best tool for the job. For example, we do not have any good production-ready languages for writing cryptographic primitives without side-channel issues. Your options are 1. Write C, use all the compiler flags you can and pray 2. Use some experimental academic thing like [FaCT](https://github.com/PLSysSec/FaCT) and pray 3. Write assembly, don't mess it up

> It highly depends on the runtime / implementation and what is more performant today could change tomorrow The trouble with this argument is that the opposite can also be true: what is more performant today may remain more performant tomorrow. I'm still waiting for JS's let and const not to be substantially slower than var , even though I'm always told that the runtime will "fix that problem" soon enough. Last I checked, C and Assembly were still considerably faster than high level languages. The issue with these languages is their safety and expressiveness, not their performance. Given that performance is one of the biggest signifiers of application success, and given how slow modern apps are today, I think there's a good case to be made that we may not have this balance entirely right

It does work because they weren't even being though the low level stuff because of this same reason. Because then why not learn that low level thing if it's better. i.e. if you start with for loops you already skip the ASM. Why do you skip it? Then they should be tought ASM instead of for loops to understand the for loops...

They should be taught ASM. ASM no longer being on the curriculum would explain a lot about the state of programming today

Vimium plugin has Shift+t tab search too. So you can use this either in Chromium or Firefox.