4 ms·

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 infrastructur

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.

zaarn 8y ago
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.
- _dps 8y ago
  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).
  - zaarn 8y ago
    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.
- skj 8y ago
  It seems a bit telling that you described one as "kernel" systems programming and the other as "system" systems programming.
  - zaarn 8y ago
    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.
    - philipov 8y ago
      I think that in user space, it is not clear what is an application and what is a subsystem. Is a database a system or an application? I could issue queries to it directly as part of some ad-hoc research, or I could build a production process using it as a component. In one use-case, it's the application, and in the other, it's just a subsystem. And so I think the distinction between kernel-space and user-space is the only one that makes sense. Once you're in user-space, the distinction between systems and applications can no longer be applied to a tool, but only to particular use-cases for that tool.
      - zaarn 8y ago
        a modern RDBMS is largely in the systems layer since it's the glue used by other application. Having a user interface doesn't really matter IMO, otherwise none of the usermode systems programming applications would be systems programming at all. Perhaps it would help to add that user software applications generally aren't intended to be used by other applications. Your browser is such an application since it's primary interface is being directly used by the user. The output and state of a browser is not intended to be consumed by other applications running on the system, though it is capable of running code to supplement the output and state of a single website for the purpose of further user interfacing. An RDBMS doesn't have such a thing, the user interface is largely what you use in the application, it's primary use case is gluing together applications like browsers or websites.
chii 8y ago
> 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.
Koshkin 8y ago
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.
- deleted 8y ago
  [deleted]

zaarn 8y ago

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.

_dps 8y ago
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).
- zaarn 8y ago
  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.
skj 8y ago
It seems a bit telling that you described one as "kernel" systems programming and the other as "system" systems programming.
- zaarn 8y ago
  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.
  - philipov 8y ago
    I think that in user space, it is not clear what is an application and what is a subsystem. Is a database a system or an application? I could issue queries to it directly as part of some ad-hoc research, or I could build a production process using it as a component. In one use-case, it's the application, and in the other, it's just a subsystem. And so I think the distinction between kernel-space and user-space is the only one that makes sense. Once you're in user-space, the distinction between systems and applications can no longer be applied to a tool, but only to particular use-cases for that tool.
    - zaarn 8y ago
      a modern RDBMS is largely in the systems layer since it's the glue used by other application. Having a user interface doesn't really matter IMO, otherwise none of the usermode systems programming applications would be systems programming at all. Perhaps it would help to add that user software applications generally aren't intended to be used by other applications. Your browser is such an application since it's primary interface is being directly used by the user. The output and state of a browser is not intended to be consumed by other applications running on the system, though it is capable of running code to supplement the output and state of a single website for the purpose of further user interfacing. An RDBMS doesn't have such a thing, the user interface is largely what you use in the application, it's primary use case is gluing together applications like browsers or websites.

chii 8y ago

> 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.

Koshkin 8y ago

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.

deleted 8y ago
[deleted]