4 ms·

I think that "how it would compile to assembly" is a shorthand for "understanding what the code does". Not many people these days can read and fully understand

I think that "how it would compile to assembly" is a shorthand for "understanding what the code does". Not many people these days can read and fully understand the 64-bit assembly code generated by llvm. I think it is less than 1% of Mac developers. C++ also have a lot of magic going on. Even C can be tricky with an optimizing compiler.

addaon 5y ago
I'd accept "how it would compile to assembly" as "understanding the machine-level behavior of the code," but again, I find this extremely lacking with Java. I don't know what percentage of developers can read assembly, but the popularity of tools like Godbolt strongly suggest it's non-zero. In my own experience, all of the most skilled developers I've worked with have been comfortable digging down to the necessary level -- and doing that in Java, or most other JIT'd languages, is just not fun. You'll notice that I very much didn't put C++ on either the "easy to understand intent" or "easy to understand behavior" lists -- while it's my preferred language and my primary language, ease of understanding is not its virtue. And while I agree that C compiled with a minimally optimizing compiler (CompCert, clang -O1, etc) is easier to understand than optimized code (for me, the sweet spot for understanding is as compiler that does good register allocation and constant folding, but only really does instruction reordering for memory ops), it's pretty rare that I look at the output of highly optimized code and am surprised or find it hard to follow. Some constructs (medium sized switches, for example) can be pain points... but most often reading assembly output from optimized C is either "yeah, that's about what I would have written" or "close, but you missed this optimization/intrinsic, I'll do it myself."

4 ms·

I think that "how it would compile to assembly" is a shorthand for "understanding what the code does". Not many people these days can read and fully understand

by silvestrov 5y ago

addaon 5y ago
I'd accept "how it would compile to assembly" as "understanding the machine-level behavior of the code," but again, I find this extremely lacking with Java. I don't know what percentage of developers can read assembly, but the popularity of tools like Godbolt strongly suggest it's non-zero. In my own experience, all of the most skilled developers I've worked with have been comfortable digging down to the necessary level -- and doing that in Java, or most other JIT'd languages, is just not fun. You'll notice that I very much didn't put C++ on either the "easy to understand intent" or "easy to understand behavior" lists -- while it's my preferred language and my primary language, ease of understanding is not its virtue. And while I agree that C compiled with a minimally optimizing compiler (CompCert, clang -O1, etc) is easier to understand than optimized code (for me, the sweet spot for understanding is as compiler that does good register allocation and constant folding, but only really does instruction reordering for memory ops), it's pretty rare that I look at the output of highly optimized code and am surprised or find it hard to follow. Some constructs (medium sized switches, for example) can be pain points... but most often reading assembly output from optimized C is either "yeah, that's about what I would have written" or "close, but you missed this optimization/intrinsic, I'll do it myself."