Assembly would be lower. You have more complex / direct instructions in assembly. Brain fuck is pretty much just a pure turing machine, and has 8 instructions.
X86 has ~ 1000 + variants. Even ARM with a smaller instruction set has 232 instructions.
In brain fuck to set a number you’d have to count up (or down - underflow) to that number. In assembly you just set it.
Somewhere I’ve read that current assembly code with Makros should be similar to writing C.
Usually a translation system might return the key value if the translation is missing. By translating with “untranslated” as a default you’d get just that text filled as fallback.
Unless you reinvent the wheel for lookup and can just ignore your magic value, or put an if on every value lookup.
If someone changes the code and forgets to modify the comment, the reader might favor one or another at random.
Hence why you should comment why, not how/what.
// slow down traffic before crossing busy main road
Now you can change the stop sign to a yield without touching the comment. Or judge that the comment can be removed if it’s clear the main road does no longer exist.
Sounds like a good use of comments. Explain why, not how. (that should be readable from the code for the most part. Unless you’re having function calls like xmmmuldp (simd) )
Don’t let yourself down because you don’t know the syntax off the top of your head.
Even after 15 years of programming, and studying computer science, I would have to look up how to write loops, conditions, variable assignments in bash / sh / batch.
Coming to python from a primarily java focus background wasn’t any different. I knew what steps the program should do, but had to look up how to translate it into whatever language. And for further improvements what features the language has to express the things “in the style of the language”