3 ms·

For me "systems programming" is just low level programming. You do it when you need to access the hardware, when you need performance. It seems a lost art. Whe

For me "systems programming" is just low level programming. You do it when you need to access the hardware, when you need performance. It seems a lost art. When I learned Pascal, C and C++ during high school most of my peers were learning and using these. Until early 2000s most of the software facing end users was quite low level because there was no way around it, people needed software that was fast enough. Even if today I use mostly a garbage collected language and I am abstracted away from the language, I find my days and years of using C and C++ quite rewarding because I understand how the hardware works, what are the trade-offs when taking one decision and what is the path forward if I want to have decent performance.

bluetomcat 4y ago
Systems programming is when you break-out from your shiny MVC API and libraries, and start reading section 2 of the Linux/BSD manual. When you start caring about process and thread affinity, memory allocation patterns, CPU cache performance, etc.
- amelius 4y ago
  And the GPU. This is why a "systems" programming language makes no sense. You need many languages to address all the different kinds of hardware in your system.
  - ungamedplayer 4y ago
    Assembly as a language meets all of these requirements. Is there an exception that assembly of some type doesn't meet ?
randomdata 4y ago
Yet an operating system is at a higher level, above the kernel. Traditionally, systems have been the middle ground between the low level and the high level. But ultimately words only mean what ever you define them as in the moment, so system can mean anything you want it to, so long as that meaning is conveyed to others needing to understand how you are using the word.
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 ago
  I 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.
pjmlp 4y ago
Which can even be done in BASIC, like on the 8 bit home computers, or the BASIC compilers available for MS-DOS, VAX/VMS, HP-UX and so forth. Xerox PARC systems programming was done in Smalltalk, Interlisp-D, Mesa/Cedar, where garbage collection was part of the picture. Likewise at ETHZ with the various kind of Oberon based systems they produced. I was lucky to have done systems level stuff in BASIC, and Pascal before getting to learn C and C++, as I wasn't subject to the misunderstanding C and C++ are the only way to do systems work. What matters is understanding how the hardware works, and actually how that high level stuff maps into Assembly.
agumonkey 4y ago
There's a slight variation on this, although I never saw it said out loud: Low level or not, system programming is about interacting parts. Long ago, low level meant sending messages/signals to various chips to have the desired effect. It was cryptic and full of time and space constraints, and people equate system with these complex topics but to me the "interacting parts of a system" is still an important aspect of the definition. That's why I accepted go being a system language, it just wasn't operating at the electronic layer, but the computer/node level.. but it was meant to orchestrate messages concurrently between all these nodes, just like chips and signals long ago.

bluetomcat 4y ago

Systems programming is when you break-out from your shiny MVC API and libraries, and start reading section 2 of the Linux/BSD manual. When you start caring about process and thread affinity, memory allocation patterns, CPU cache performance, etc.

amelius 4y ago
And the GPU. This is why a "systems" programming language makes no sense. You need many languages to address all the different kinds of hardware in your system.
- ungamedplayer 4y ago
  Assembly as a language meets all of these requirements. Is there an exception that assembly of some type doesn't meet ?

randomdata 4y ago

Yet an operating system is at a higher level, above the kernel. Traditionally, systems have been the middle ground between the low level and the high level. But ultimately words only mean what ever you define them as in the moment, so system can mean anything you want it to, so long as that meaning is conveyed to others needing to understand how you are using the word.

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

pjmlp 4y ago

Which can even be done in BASIC, like on the 8 bit home computers, or the BASIC compilers available for MS-DOS, VAX/VMS, HP-UX and so forth. Xerox PARC systems programming was done in Smalltalk, Interlisp-D, Mesa/Cedar, where garbage collection was part of the picture. Likewise at ETHZ with the various kind of Oberon based systems they produced. I was lucky to have done systems level stuff in BASIC, and Pascal before getting to learn C and C++, as I wasn't subject to the misunderstanding C and C++ are the only way to do systems work. What matters is understanding how the hardware works, and actually how that high level stuff maps into Assembly.

agumonkey 4y ago

There's a slight variation on this, although I never saw it said out loud: Low level or not, system programming is about interacting parts. Long ago, low level meant sending messages/signals to various chips to have the desired effect. It was cryptic and full of time and space constraints, and people equate system with these complex topics but to me the "interacting parts of a system" is still an important aspect of the definition. That's why I accepted go being a system language, it just wasn't operating at the electronic layer, but the computer/node level.. but it was meant to orchestrate messages concurrently between all these nodes, just like chips and signals long ago.