Why is programming in bytecode not as popular or prevalent as programming in assembly?

You see assembly code and assembly coders all over the internet but there's a开发者_如何学编程lmost nothing on bytecode. Why is that ? The needs and the advantages of programming in assembly should all hold for programming in bytecode too.

Another reason why bytecode programming is far less popular / common than assembly programming is the genericity of bytecode - its simplicity.

Bytecode instruction sets are largely "ultra-RISC", very simple instructions. Designed for two purposes, to provide the virtual machine with the ability to quickly translate / map into a native instruction set and to allow a high-level compiler to easily create near-native bytecode.

Assembler, on the other hand, also has such simple generic parts - and those are the ones that the bytecode interpreter / just-in-time compiler will actually use to implement bytecode functionality. Few people exclusively use these parts of a native instruction set to write assembler programs. The (Just-in-time-)compiler does that for you.
But assembler has much more than that, especially SIMD / vector instructions. These instructions are special-purpose and highly efficient for very particular workloads ("data streaming", in the widest sense - anything that churns through data like dracula through ladies' throats). To this date, there's situations where a bit of human intervention can surpass a compiler result by orders of magnitude. Doing so often requires the use of such vector instructions, in a particular way that the compiler may not be coerced into doing for you.

The price to pay is having to write a native assembly function.

Bytecode lacks these special-purpose instruction extensions, and extending bytecode like that would give away one of the largest advantages of having bytecode in the first place. It would make it unportable between CPU types - the vector extensions of, say, x86/x64 (SSEx), ARM (Neon) or PowerPC (AltiVec) are too different to map a single shim layer on top.

As far as teaching assembly-level programming goes, one doesn't need an actual CPU instruction set for that; Donald Knuth in "Art of Computer programming" has used a "virtual" assembler called MIX/MMIX for so long that it predates the existance of the word "bytecode" by a few decades. Concepts that one can teach via x86 assembly language one could also teach via .NET bytecode.

But the main reason (beyond academia, see prev paragraph) why people write assembly language - to exploit platform-specific optimizations made possible by special instruction set extensions - is not a valid reason to write bytecode directly.

Most bytecodes (all of them I've seen, anyway) are designed to be an easy target to compile for. With x86 (for example) you can gain a fair amount with hand written assembly, because it's such a pain to compile for. It's much easier to compile for Java byte codes (for one example) so the gain from writing them by hand tends to be comparatively small.

.NET makes it a bit easier to write programs that generate and use its IL, so it tends to happen a bit more there, though in all honesty most of the examples I've seen looked to me like they were done almost as much because it was there as because it was really necessary.

I have doubts about your claims of popularity of programming in assembly, but that's besides the point.

The answer is simply "because there isn't any need to". Artificial assembly languages are designed to service the need of the language for which they are designed, and have a very close relationship with them rather than hardware. There's not much than can be done with them that can't just as easily be achieved in the higher-level language.

Another reason for the popularity of assembly that does not apply to bytecode, is that sometime you need to use assembly (e.g: when writing certain CPU-dependant portions of an OS).