Re:What Is Systems Programming, Really?
by sillybov3456 on Saturday March 11, 2023 @11:05AM
(#35109473)
This is the only sensible answer. I disagree with the old-school definition in which systems programming is necessarily concerned with hardware imposed resource constraints, I think that definition lost it's relevance somewhere between 1990-2010. If it's just resource constraints, then the majority of what we would think of as systems programming (like core operating system utilities and whatnot) arent really systems programming anymore since those constraints have largely disappeared (and implementations have in some cases stopped caring about the now not very important constraints as a result).
So it really comes down to who your customers are. If your primary customers are other programmers and they are using your program programmatically, then you are most likely doing some kind of systems programming.
That's the only definition that makes sense and maintains a (reasonable if not somewhat arbitrary) distinction between systems and applications once you account for many systems programming tasks no longer being constrained all that severely by hardware, and we recognize that many applications programs have grown and fit the definition of a systems implementation in terms of complexity and number of interacting pieces (another commonly cited definition of systems programming that no longer makes sense. This would necessarily mean that something like Amazon.com is a systems program, which nobody would agree with intuitively).
The value in maintaining the distinction into the present day is mostly in the way it sheds light on various user interface and portability concerns. As in, as a systems programmer must take a very different approach to user experience (since your users are either other programmers of programs) compared to applications programming. A graphical user interface on a web portal is probably not a good idea (at least as the base/primary ui) for a program that is used by other programs and programmers, but it may be a great idea for an application. On the other hand, CLIs make it easy for other programs and programmers to compose functionality with other programs and modules, and so a CLI being the primary interface is a good (but maybe not quite sufficient) indicator that you are probably working with a systems program.
So it really comes down to who your customers are. If your primary customers are other programmers and they are using your program programmatically, then you are most likely doing some kind of systems programming.
That's the only definition that makes sense and maintains a (reasonable if not somewhat arbitrary) distinction between systems and applications once you account for many systems programming tasks no longer being constrained all that severely by hardware, and we recognize that many applications programs have grown and fit the definition of a systems implementation in terms of complexity and number of interacting pieces (another commonly cited definition of systems programming that no longer makes sense. This would necessarily mean that something like Amazon.com is a systems program, which nobody would agree with intuitively).
The value in maintaining the distinction into the present day is mostly in the way it sheds light on various user interface and portability concerns. As in, as a systems programmer must take a very different approach to user experience (since your users are either other programmers of programs) compared to applications programming. A graphical user interface on a web portal is probably not a good idea (at least as the base/primary ui) for a program that is used by other programs and programmers, but it may be a great idea for an application. On the other hand, CLIs make it easy for other programs and programmers to compose functionality with other programs and modules, and so a CLI being the primary interface is a good (but maybe not quite sufficient) indicator that you are probably working with a systems program.