Brief thoughts on maybe programmers are bad talk

I love the title, though the talk isn't quite a match. Whatever. The link is here: https://www.youtube.com/watch?v=qqUgl6pFx8Q

Overall I thought it was a good discussion, but I'd have challenged Casey a bit more on the assembly stuff. And as usual he has some perspectives I really disagree with at the level he presents them at, but I think if we could talk and dig into it more we'd probably agree on a lot. He might even say my very poor understanding of certain things is sufficient for his goals, and that if everyone was at least as poor as me, things would be better. Perhaps. Anyway, remarks just on the assembly stuff for now.

Can you really learn to read assembly well without having to write a good amount of it? I'm skeptical. The reason I'm skeptical is because it doesn't actually help that much to know "xadd [r13+16], r14" means "exchange and add" etc. The reason assembly is so difficult to understand and to write in general, despite for each line it being trivial to know (in a platonic sense) the full before/after instruction state of the CPU, is that what we care about is almost always about the side effects at some other level of looking at things (I don't want to say abstraction). Those side effects can be very platform and hardware dependent, the mapping very custom, and I think it's hard to get a feel for how such mappings work just by reading, you need to write. There's a reason every computer engineer learns to write UART, SIP, and I2C protocol code, whether in C or assembly, and often has to inspect it with an oscilloscope: you can't learn well enough just looking at the block diagrams.

(In fact I think this is the fundamental difficulty of programming and why it's so new in human innovation: it's difficult to say that when this thing happens, it really maps to this other thing. If the voltage level of this thing is this level or higher, we treat it as a logical 1, if lower, a logical 0. If we have a bunch of these fake 0s and 1s in a particular pattern and feed it to this other thing, we have made an RGB image appear on a screen totally separated from our CPU. Pointers are often said in intro courses to be scary hard things, but it's just the same issue: the symbol is not necessarily the substance, the pointer is not the thing it points to.)

Anyway, if you can't really get decent at reading without doing some amount of writing, then pedagogy issues arise. Another comment mentions that NES games is the best way, another mentions a PIC controller with some custom hardware, perhaps Minecraft Redstone is the best way... these are all idiosyncratic, it's what people prefer, which of course differs. I didn't enjoy any assembly until PIC and older ARM myself, I still detest dealing with x86, but it's the world we live in. Writing fun stuff in not-x86 but still learning how to read most x86 would be my approach.

On the comparison of one NAND gate vs. a whole complex tetris built out of NAND gates, and mapping that analogy to assembly vs. some JS framework, it's right in the sense of simple vs. complex, but simple/easy and complex/hard are not the same thing. (Rich Hickey has a famous talk on that.) In fact, despite how simple and rather easy NAND gates are to understand, I think it's even easier for someone to start playing tetris and learn and understand what's going on. Things have gotten the way they are because it's easier, and culturally we're obsessed with apparent ease over all else. Performance, simplicity, beauty, rewards for mastery, or anything else, it's all subservient to apparent ease. Apparent ease comes first, to ourselves but also to our end users. (There's a related sub component that sometimes comes up too I think around ease and difficulty of hurting oneself. What could be easier than just editing a pre-populated text field with some custom stuff? But someone might enter wrong text! So no, we must make a convoluted GUI Wizard to make sure that the end text can only be certain ways no matter how stupid and careless the user is, and what can be easier than clicking a few buttons one screen at a time?)

On the local level, yeah, an assembly instruction isn't complex, even intel's craziest ones are mostly just crazy, not that complex, their non-local effects are fully documented. But it's the collection of them that gets you, and again the side effects that you actually care about usually at higher levels. And you have very few higher level abstractions to help understand, whereas a higher level programming language gives you those as primitives and enforces them. So to me, assembly language in general is actually closer to the mass of NAND gates. It's not assembly vs. big framework, but one assembly instruction vs. a whole assembly program. When I think "know assembly", I think "able to read the code for a game like roller coaster tycoon or a NES game and follow it and understand how things correspond to various behaviors." I do agree that there's value midway, like being able to understand a single function on godbolt, or just the body of a for loop, or the handful of instructions needed in a specific order to implement a context save... But you just need broader understanding to get anywhere, being able to say what each line does locally won't give that to you. The special case of knowing whether to loop over y or x in the inner loop of a 2d array is understandable with or without assembly, but even if the assembly is easy to understand it won't help you with the context save code. It's also just not even close to the cause of most performance problems.

There's a funny project called movfuscator, it compiles everything to mov instructions. Each instruction is trivial to say what it does. But you're hopeless for understanding the behavior of the whole. Meanwhile, despite how e.g. fetch() in browser JS is this crazy function call doing all sorts of complex stuff... it's easy to understand what it's doing and also what it's not doing (despite the complexity, it's not going to follow a path that touches your gpu). Your mov is only putting memory from here to there but the side effects of that are harder to predict, maybe your GPU starts doing something after one!

---

Posted on 2024-11-17 by Jach

Tags: programming, thought

Permalink: https://www.thejach.com/view/id/438

Trackback URL: https://www.thejach.com/view/2024/11/brief_thoughts_on_maybe_programmers_are_bad_talk

Back to the top