A classic "easy" thing that appears "hard": write a little bit of assembly. Note, a little bit[1].
Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. The key is you need to write and debug a little at a time.
Case in point, I wrote an entire Wasm interpreter[2] in x86-64 asm over the past few months. I wrote it a little at a time, had lots of unit tests, and am working in an engine that was already completely functional (with a slower interpreter).
[1] If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail. If you find yourself writing more than a few thousand assembly instructions, total, you have probably have already failed.
Isn't it better to write the entire thing in a higher level language like C first, then start optimizing the slow parts e.g. by writing them in assembly?
Sometimes writing asm is just to get access to certain instructions or states not exposed in C. Particularly on embedded platforms. But generally, I agree that you should write most, if not all, in a higher-level language first.
For all our embedded work, we first prototype (something we always call a simulator which it kind of is) in typescript (used to be c#), then port to c => if we need 'less' (the c version is too big, too slow etc) we port it to asm. The advantage of this way is that we already know it meets the demands of the business (because we fleshed that out with the typescript version) and we have a low level version (c) that corresponds in functionality as we can test the 2 versions in the same way. Moving to asm is still a pain, but far less painful than other ways we tried in the past (like when I did a lot of straight to asm in the 80s, which was very painful, but there was no real way, except for some algorithms, to do the 'simulator' step here).
I find that I make a lot of mistakes with asm. When you've written hundreds of asm instructions in one change, because of debugging is superlinearly hard, one can easily spend a lot of time debugging. So now I write and commit in small chunks and test repeatedly. This has made me much more efficient by drastically reducing the time searching for where in the hundreds of instructions I've gone wrong.
Writing assembly, again, in small amounts, is exactly the kind of thing that is difficult to start, and fails spectacularly if you have little experience. Debugging is a pain. But you can totally get the hang of writing assembly, and as long as you are doing it for the right reasons (TM), it's justified, and heroic. The key is you need to write and debug a little at a time.
Case in point, I wrote an entire Wasm interpreter[2] in x86-64 asm over the past few months. I wrote it a little at a time, had lots of unit tests, and am working in an engine that was already completely functional (with a slower interpreter).
[1] If you find yourself writing more than a hundred or so assembly instructions in a sitting, you are going to fail. If you find yourself writing more than a few thousand assembly instructions, total, you have probably have already failed.
[2] https://github.com/titzer/wizard-engine/blob/master/src/engi...