Comment by antirez
7 years ago
My idea of system programming is that, other than the "near to the bare metal" element, which may not be always true, has this quality of creating infrastructures for other layers to use. A game 3D engine and a DNS server may be both written in C++ and may use the same low level programming techniques to achieve speed, but the fundamental difference is that one is just part of an application program of some type, and the other a system that provides a general service to other programs. So clearly it's technically possible to do system programming in higher level languages, even if often this will require anyway dealing with many system calls regardless of the language, both explicitly or implicitly via abstractions.
Computer systems are only useful because they can run application programs. "Systems programming," therefore, is one that aims to improve the utility of the computer, as opposed to "application programming" which solves concrete problems posed by users.
> part of an application program of some type, and the other a system that provides a general service to other programs
I find that distinction to be a bit arbituary. To me, systems programming is one which require adherence to some sort of well defined spec/standard so as to interoperate with some (potentially underlying) "system".
In a 3D engine, the systems programming part is the part that interfaces with the graphics drivers, but not the part that derives the 3D geometry from reading files or running logic to generate the content.
In a DNS, the systems programming part is the socket interface, but not the DNS protocol (tho you could argue that the protocol is also considered "system-ish").
In a web application, the systems programming is also the socket, in a very similar vein to DNS servers.
In a desktop application, the systems programming is the interface into any native resources (such as any socket calls, any disk, or peripherals, as well as any of the graphical hardware interfacing required).
But because many of these tasks are quite common, they get put into libraries, and so many application programmers do not deal with these "systems" part, and just deal with their own application logic, and so it feels like there's no systems programming.
I think systems programming should be split in two, honestly.
You have the kernel-level systems programming where you need to be near the bare metal, where you write kernels or program microcontrollers with less RAM than a x86 CPU has L1 cache, where taking a microsecond longer can mean the overall system crashing (or even costing a human life).
And you have system-level systems programming where you write services and supportive infrastructure to enable user programs, where garbage collection and non-realtime behaviour is acceptable, where you can skip a microsecond and it'll be alright.
I think the two "poles" you've identified are good ones (~microseconds matter and ~100ms matters) but there's a wide range in between. If you do anything with video at modern resolutions, then you're in the single-millisecond-matters regime (this includes games as mentioned upthread, and just about anything in VR as well).
Video streaming and gaming have some soft realtime guarantees, yeah, though generally these aren't systems programming and application programming instead.
The plumbing below, ie graphics rendering pipeline, tend to fall into the category of kernel systems programming, controlling the GPU is pretty close to doing what a kernel does IMO.
It seems a bit telling that you described one as "kernel" systems programming and the other as "system" systems programming.
Well, I think the distinction is fair, kernel systems programming is largely concerned with things a kernel would normally do (ie, a kernel or µC code), very close to the metal or such. Maybe bare metal systems programming would have been more accurate but I feel it doesn't convey the same meaning.
System systems programming is what it says on the tin; it's about constructing systems, multiple objects interacting with rules on the interaction, etc. An alternative name might be "user space systems programming" though again I think that doesn't convey the meaning as well.
3 replies →