The article focuses on writing great code, but there's another reason to learn assembly language: for some specific aspects of a machine that were not modelled

The article focuses on writing great code, but there's another reason to learn assembly language: for some specific aspects of a machine that were not modelled in the higher level languags, this may be the only way to go. For example, for HP Integrity Virtual Machines (sort of VMware for HP big iron servers), I spent a lot of time writing low level vector code that just cannot be written in any other language because it executes in some specific restricted environment that the C compiler cannot deal with. Specifically, it runs off a few reserved registers, has no valid stack (a TLB handler may be triggererd by a TLB miss on the stack), and frequently use instructions that are at best supported by compilers as inline assembly. So it's not just about performance or style, it's also about semantics. And that's part of the reason why in XL, all low-level operations are connected with the machine explicitly. I reasoned that what worked for an addition would alo work for a more bizarre machine instruction. So in XL you have for the imperative dialect: function Add(x,y:integer) return integer written x+y is XL.Bytecode.Add And for the functional dialect: X:integer + Y:integer as integer -> opcode Add The list of opcodes is machine specific, but the way to connect to them is not. Does not solve the whole problem, e.g. The compiler still has to assume things like "there's a stack", but getting closer to connecting machine and high level languages.