[beagle3]

> I'm an assembler hog and any language that doesn't compile to native code is just a toy to me.

First, what exactly is native code? Is it the PythonVM/JVM byte code? The x86 code it is JITted into? The microcode that interprets the "native" x86 code? You probably mean the x86/ARM/whatever bytecode, but that's not a trivial definition.

Practically speaking, compiling to "native code" is mostly useful given a known architecture. "rep movsb" used to be the fastest way to copy memory around; and then it was slow as mollasses; and then it was fast again. Table lookups were the fastest way to do 6-bit by 8-bit multiplications up until the 386 or 486 - and then the multiplier became faster than memory.

Somewhat surprisingly, J (and APL and K) tend to focus on promoting those things that have always been true - e.g. sequential access is much faster than non sequential; branch free code is better than branching code; small code/data that fit in cache/main memory is better than larger code/data that doesn't. The computation model fits modern CPUs and GPUs very well, despite being approximately the same one since the 1950s.

It's a different take on the "better algorithms beat faster implementations" - a good language that makes a good fast solution intuitive is often, in practice, better than one that can be faster with a lot of intricate work.