alt Hacker NewsThe best way to go about that is to use a simulator for an old cpu like EdSim51[0]. Can do a lot of things with just a few lines of code.
> it's complexity in the sense of "I put the wrong bit in the wrong spot and everything is broken with very little guidance on why, and I don't have the mental model to even understand
That's the nice thing about assembly, it always works, but the result may not be as expected. But instead of having a whole lot of magic between what is happening and how you model it, it's easy to reason about the program. You don't have to deal with stack trace, types, garbage collection and null pointer exception. Execution and programming is the same mental model, linear unless you said so.
You can start with assembly and then switch to C or Python and tell them: For bigger project, assembly is tedious and this is what we invented instead.
Replies
No, assembly doesn't "always work". It almost always does something, true, which is the worse thing about it: instead of getting some error, you get to figure out why the value at the end of your program is not the value you expected, and which of the hundred instructions before that caused it to be wrong.
I vote for microcontrollers. I learned assembly on Atmel's AVR and it's was easy and straightforward because there's very little abstraction underneath, there's no OS, no heap, no multiprocessing and no context switching, no syscalls and no fat libraries, and you get direct access to the hardware. You also receive actual physical feedback — doing a tiny bit of bit fiddling gets you a blinking LED or whatever.
AVR's assembly is quite mediocre, with 120+ something instructions, with lots of duplication among them (IIRC — it's been... many years already), and some people swore by PIC which only had 35 instructions to remember. But it was still easier than lobotomizing oneself by trying to write a Win32 application in x86 assembly (which came later... and went to the trash bin quickly while microcontrollers stuck for much longer).