It is very weird.. this code is is full of the duplicative, hard-coded constants, something which I would avoid in any software I write.
For example, take a look at the display module [0] -- this 190-line program contains over 20 instances of constant "128", in lines like those:
sa := base + u0*4 + sy*128; da := base + v0*4 + dy*128;
What does this mean? See, there is only one display supported by this OS -- an 1024 x 768 monochrome one. Since this is monochrome, you only need one bit per pixel, and you can put 8 of them in the byte. If the pixels are sent out serially and lines follow each other in the buffer, then start of each line is (1024 / 8) = 128 bytes apart.
But instead of writing something like "const LineStride = Width / 8", the code just hardcodes the value all over the place.
It wasn't designed for any other display. You can pretty much treat 128 as a symbol and leave it as that. Until you have more than two of those 190-line programs that target different displays, there's no point of refactoring it. ---my guess
Sure, but that’s an extremely shortsighted assumption. Engineering projects change scope over time. Maybe that particular arbitrary decision won’t change, but there must be 1,000 other decisions, some of which might be revisited at some point. There’s no need to artificially handicap yourself for zero benefit in return.
Never mind that you’re introducing the possibility for bugs: the compiler would catch if you type the wrong symbol name, but not if you type 129 accidentally.
And anyone reading or maintaining that code now has several additional needless WTFs they’ll encounter in the course of making sense of it.
There's two aspects here. First, "wasn't designed for" and "the future" usually means changes will happen.
But more importantly, by giving it a name the code is more self-documenting. New and old programmers don't have to figure out why 128, or if 128 is right or not in this bit of code.
Exactly. Recently, when Wirth couldn't find an OS with a device driver for his favourite mouse, he built his own hw + OS + userland combination so he could keep using the mouse he got as a souvenir of his Xerox sabbatical. (I believe the monitor and keyboard were off-the-shelf.)
He's not primarily a programmer, but a computer engineer. It wasn't his first computer system, and may not even be his last. The mouse stays the same size, but the computers themselves have shrunk dramatically over the years. Maybe when he turns 90 he'll ship-in-a-bottle build a computer inside his favourite mouse?
For example, take a look at the display module [0] -- this 190-line program contains over 20 instances of constant "128", in lines like those:
What does this mean? See, there is only one display supported by this OS -- an 1024 x 768 monochrome one. Since this is monochrome, you only need one bit per pixel, and you can put 8 of them in the byte. If the pixels are sent out serially and lines follow each other in the buffer, then start of each line is (1024 / 8) = 128 bytes apart.But instead of writing something like "const LineStride = Width / 8", the code just hardcodes the value all over the place.
[0] https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Displ...