What Is Systems Programming, Really? (2018)
willcrichton.net
willcrichton.net
It has nothing to do with the actual programming language.
I wouldnt but that sounds like something we would all read about on HN.
Personally I use go for everything.
Here is some stuff to get you started,
"The Cedar Programming Environment: A Midterm Report and Examination "
https://pdfs.semanticscholar.org/33ff/212245ff8af0359e911883...
http://www.ocp.inf.ethz.ch/wiki/Documentation/Front
https://www.whoishostingthis.com/resources/modula-3/
http://joeduffyblog.com/2015/11/03/blogging-about-midori/
https://www.infoq.com/presentations/csharp-systems-programmi...
(My personal opinion is that the whole discussion is moot, a "systems programming" category is ill-defined and not needed.)
My understanding is that, in effect, "Systems Programming" is analogous to "Operating Systems Programming", or rather you might say (given the increasing size of operating systems these days) that "Systems Programming" is a subset of "Operating Systems Programming" that deals with the direct manipulation of memory in order to provide a useful abstraction for "user" software - remembering that most hardware interaction is via memory. Obviously, in order to do "Systems Programming" you need a "Systems Programming Language" that allows such direct access to memory.
These days, "Systems Programmers" would be those working on the Linux kernel, or microkernels, or graphics drivers (basically those who have complete access to memory) though those developing services one layer up might also consider themselves to be such (especially micro-kernal-based operating systems).
It is probably worth emphasising that "System" is a generic term that is used in a lot of different contexts. I think "Systems Programming" is used in the context of a "Computer System", while modern day cloud programming would be better described as "Distributed Systems Programming" as it is in the context of a "Distributed System" (though I've probably just annoyed a whole bunch of distributed systems researchers).
I think that what the author of the article is talking about is "System Architecture" (or perhaps "Distributed Systems Architecture").
Should we talk about this as programming at all?
Indeed. When people call something "systems programming" when it is just e.g. server programming, it feels like when you are being told that "hacker" means the same thing as "cracker" because that's what most people think it means.
In my slightly angry opinion, "Systems programming" is one of those terms that are convenient because they are vague and look cool. The plural on "systems" is suspicious in itself. It's not just one system they are working on, but many. Impressive, isn't it? The funny thing is, if you look up the definition of "system":
a regularly interacting or interdependent group of items forming a unified whole
... not so many people actually do that. I think programmers usually work on one thing, one component of a whole system (guess why you are part of a team?). I'm not sure about how uncommon the opposite is because I actually do that - I have worked at the driver level, OS configuration level and at the application level in order to make a product work - and I am not that much of an exceptional programmer.
What is sytems programming? I don't know. I don't care either. It's an arbitrary label that is rarely used and doesn't affect anyone in any way.
Alternate definition whose source I can't recall:
Systems programming is everything that isn't application programming.
Maybe it's time to update that with:
Systems programming is everything that isn't application programming or low-level programming.
;)
Slightly more seriously, systems programming seems to me to be approaching the lowest levels, so including "not low-level programming" would give the wrong impression that it includes the really high-levels ones.
My education is in relevant skills (CompE), but the attitude I keep running into in this domain has really started to disgust me, even if it isn't everyone. When it's people I've seen in leadership, that's enough :/
It's because they are.
I have 15+ years of experience in hl programming and almost none in low level, yet I feel like at home with bare metal stuff. And it is a lot of fun as well.
As for the systems programming please see my answer to a sibling comment.
And you misuse this word, try googling what it really means.
Also, at a high level, you typically solve different, bigger/harder problems. Someone may use Python to build a statistical model, but using a simple language that even kids use at school, doesn't mean the task would be easy.
This is also reflected in salaries here where I live - embedded devs don't earn more than application devs.
Bjarne Stroustrup: "Systems programming came out of the field where you had to deal with hardware, and then the applications became more complicated. You need to deal with complexity. If you have any issues of significant resource constraints, you’re in the systems programming domain. If you need finer grained control, then you’re also in the systems programming domain. It’s the constraints that determine whether it’s systems programming. Are you running out of memory? Are you running out of time?"
These constraints lead to the level of complexity which many programmers are unable to deal with. Another source of the complexity is hardware itself -- it is asynchronous and opaque.
But there's literally _nothing_ inherently special or impressive about low-level systems programming or programmers :) I'm pretty confident good problem solvers from the domains I mention above could learn to work on it as easily as anything else.
And my original comment was about a common _attitude_ I've observed that is the opposite of what I'm saying. And you aren't really making any points against that haha
My point is that the bar in the 'systems programming' is indeed set higher than in many other domains.
I'm not a systems programmer, but I've seen competent in their own domain programmers taking on tasks in more complex domains and failing where I didn't and I've been myself on the failing side.
And please refrain from personal attacks, I myself love sharing knowledge with colleagues.
I don't see any personal attacks in my comment, outside of the fact that my original issue was with how a culture of people I've encountered carries itself.
Perhaps I misinterpreted your comment.
Application programming concerns the code between kernel and the ordinary user.
Essentially, systems programmers write software that application programmers can interface with. Application programmers write software that ordinary users interface with.
It gets fuzzy at the edges like most definitions, but that's how I think about it generally.
I think conceptually this is a better test, more so than say if you have access to a raw pointer - because more important parts of how to handle core issues like scheduling, storage management, concurrency, parallelism and distributed computation manifest themselves in many forms.
I started my career doing C programming in a OS / kernel environment. In retrospect a lot of pieces of applications I've worked on are what I think of as systems, and many parts of kernels are more applications than systems.
If you're going to say something like "but the kernel should be fast when servicing syscalls", you are right, but that is not a resource constaint, it's a user requirement. LibreOffice should also be fast when reacting to my keypresses, but I hope we agree that LibreOffice development would fall into the "applications development" camp, if we have to put things into bins.
The truth is, we don't have to put things into bins. There is no need for a muddy, fuzzy term like "systems programming". If you're doing "kernel programming" or "embedded systems programming on resource constrained microcontrollers", you can just say that directly.
Specially jarring because it's out of nowhere. That conclusion does not follow from everything that comes before.