4 ms·
The problem with that distinction is that the word “system” doesn’t get to have a say in any of it. A system is something that is put together from smaller, di
by dgb23 4y ago
The problem with that distinction is that the word “system” doesn’t get to have a say in any of it.
A system is something that is put together from smaller, distinct components in such a way that it has emergent properties not inherent in its components.
Is systems programming to provide such components so they can be put together by application programmers?
If yes, then “lower level” is entirely relative. A component might be a hardware driver, a service in the cloud or a set of primitives in your game engine.
This would also mean that the term is recursive. Anyone who is programming components or larger parts of a system that can be put together is now systems programming.
So the web developer who handles content negotiation for both end user consumption (html) and further processing (json) is now systems programming?
It’s all a bit confusing with this term.
- cmrdporcupine 4y agoI see it as "systems programming" is building the "systems" that one later assembles into applications. "Applications programming" is building user facing applications, mostly out of systems others have built. e.g. I work for a company that makes a database. Even though I work in a higher level language (Julia), it's still systems development because it's concerned with systems-level concerns: building a system that is normally off the shelf, and being concerned with memory bandwidth, fragmentation, cache misses, etc. And it's not that application level engineers don't have to be worried about these things. It's just a matter of degrees or emphasis. When employed doing "application programming", I consider it bad practice to build systems from scratch. e.g. rolling your own queueing system or database when the real job is integration and solving the customer's business requirements.