I would say that systems programming is writing software to support users of a system - those using the operating system. The same users might also be using application software - say an accounting package. Maybe the application software interacts with particular systems software, maybe not.
The implementation language doesn't matter. An example of a systems program is a distributed printer spooling program I wrote in ReXX on VM/CMS in the mid 80s. All of our VM/CMS users used it, because it was far more convenient than IBM's offering, and supported our pre-existing line printers and the physically distributed nature of our organisation.
I tend to agree, but not quite fully. To me, it's not about low-level vs. high-level or distributed programming. Systems programming tend to fall into these categories:
- Running and managing a single system: kernels, drivers, programming tools (compilers, interpreters, assemblers, libraries, linkers, loaders, etc), admin tools, package managers, graphics servers, etc.
The author completely misses the point that the term "systems programming" is an abbreviation for "operating systems programming". His entire argument seems based on this misunderstanding. Time for a re-write.
I seem to recall that "systems programming" was initially penned meant what we now call "application development" [1]. I realize that these days, the two tasks are considered very different, but as far as I understand, that's "just" because we now have access to high-level APIs, the likes of which didn't exist when the name was invented.
In my book, it's "system programming" when you are writing an application and you need to reach to lower-levels than what your language/stdlib/framework typically allows. So the authors of the DeepSeek training mechanism were doing system programming when optimizing communication between cores, but also anybody who sets out to optimize a Python-based app by writing a Rust module, or a Rust developer when they're calling directly into libc, or a C developer when they're writing assembly or performing syscalls, etc. Of course, by this definition, there's no such thing as a "systems programming language", but there are languages that can serve for system programming of other languages.
[1] Which seems to be confirmed by the article, in fact.
> "systems programming" is an abbreviation for "operating systems programming"
I don't think this is right. Systems programming is a broader term that can include embedded systems, compilers, virtual machines, game engines, etc. At least that's my perception based on how it's commonly used.
I would say that systems programming is writing software to support users of a system - those using the operating system. The same users might also be using application software - say an accounting package. Maybe the application software interacts with particular systems software, maybe not.
The implementation language doesn't matter. An example of a systems program is a distributed printer spooling program I wrote in ReXX on VM/CMS in the mid 80s. All of our VM/CMS users used it, because it was far more convenient than IBM's offering, and supported our pre-existing line printers and the physically distributed nature of our organisation.
To quote myself elsewhere, systems programming is first and foremost cost center, not value center, programming.
That explains why it's a bit dangerous for the programmer's career.
How would you explain performance improvements? Enabling new hardware or new use cases that existing systems do not support?
That sounds just like reducing a cost center to the point where new things become viable?
I tend to agree, but not quite fully. To me, it's not about low-level vs. high-level or distributed programming. Systems programming tend to fall into these categories:
- Running and managing a single system: kernels, drivers, programming tools (compilers, interpreters, assemblers, libraries, linkers, loaders, etc), admin tools, package managers, graphics servers, etc.
- Connecting multiple components/systems: protocol implementations (tcp/ip, rpc, etc), message brokers, servers/daemons (database, web, cache, etc), proxies, middleware, etc.
- Virtualization: emulation, sandboxing (docker, wasm), hypervisors, etc.
Past discussions:
https://news.ycombinator.com/item?id=35092049 - March 2023
https://news.ycombinator.com/item?id=21731878 - December 2019
https://news.ycombinator.com/item?id=17948265 - September 2018
The author completely misses the point that the term "systems programming" is an abbreviation for "operating systems programming". His entire argument seems based on this misunderstanding. Time for a re-write.
Is it?
I seem to recall that "systems programming" was initially penned meant what we now call "application development" [1]. I realize that these days, the two tasks are considered very different, but as far as I understand, that's "just" because we now have access to high-level APIs, the likes of which didn't exist when the name was invented.
In my book, it's "system programming" when you are writing an application and you need to reach to lower-levels than what your language/stdlib/framework typically allows. So the authors of the DeepSeek training mechanism were doing system programming when optimizing communication between cores, but also anybody who sets out to optimize a Python-based app by writing a Rust module, or a Rust developer when they're calling directly into libc, or a C developer when they're writing assembly or performing syscalls, etc. Of course, by this definition, there's no such thing as a "systems programming language", but there are languages that can serve for system programming of other languages.
[1] Which seems to be confirmed by the article, in fact.
> "systems programming" is an abbreviation for "operating systems programming"
I don't think this is right. Systems programming is a broader term that can include embedded systems, compilers, virtual machines, game engines, etc. At least that's my perception based on how it's commonly used.
Programming for systems, duh.
I wish bcantrill would chime in and tell us his opinion, as somebody that’s been doing actual systems programming for the last 20+ years
cantrilljuice, cantrilljuice, cantrilljuice