Systems Programming

2025-04-29

Apr 29, 2025

"Systems programming" isn’t done using PUSM (Programming Using the SICP Method). If you were to write UNIX or to write a kernel for coroutines, you need to fool with stacks and bytes and you don't use FP nor Garbage Collection nor Virtual Memory nor PLs that insert checking code. Those methods make programming of compute-ations easier, but, they don't apply to "systems programming".

Odin arises from the gaming community, which is more related to "systems programming" than to compute-ation. When writing games, you want hot code and can't afford inefficient conveniences like above. In the early days, games didn't crash because game programmers performed Q/A and because market forces punished games that crashed. I'm not a game programmer, but it is my impression that modern games are bloatware and crash more often than they did in the past.

A non-gaming example is MacOS. MacOS is a systems program. My Mac needs a preventative reboot once a week or else it begins to misfunction in strange ways that look like state is being handled by PUSM-inspired programmers who believe that state can be vehemently ignored ...

Ironically, we are learning (the hard way) that game programmers don’t need all of the doo-dads that have been added to CPUs and to operating systems. Graphics-specific work is punted to specialized hardware, like GPUs. Game programmers don’t need elaborate general purpose languages anymore. They need coordination and punting languages, they need GPU-specific languages.

Building tools that protect the programmer from making dumb mistakes AND building tools that produce really hot machine code are 2 different things. You can't build just 1 language that does both. You have to build multiple languages. This is not done at the moment. There seems to be a belief that you can have an all-in-one language. I disagree. One could imagine a checker "language" that warns programmers that they’ve written code that will segfault. The checker should emit machine code that doesn't contain any checking (since it all gets checked at compile time, in theory). Shipping code to users (like my 100 y.o. mother) that still contains checks is wasteful and inefficient. But, that's what PUSM programmers do. Languages that check your program are tools for programmers. Production Engineers should be paid to optimize the code before the product ships. But, that's not what we do. My mother has to pay $$$ for laughtops and operating systems that are meant for solving PUSM-developers’ problems, not her problems. Our current programming workflow is PUSM-developer-centric and ignores end-users' needs and ignores the needs of “systems programmers”.

Programming Simplicity

Discussion about this post

Ready for more?

Programming Simplicity

Systems Programming

2025-04-29

See Also

Discussion about this post

Ready for more?