Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Is Systems Programming, Really? (2018)

willcrichton.net

Post reply on HN
Print view View original

11–20 of 81 posts

Re: What Is Systems Programming, Really? (2018)

#11

Post by mtlmtlmtlmtl »

Jiocus wrote: post #6
namaria wrote: post #4

The expression is redundant isn't it? Only systems can be programmed. You can't program a cinder block or a cardboard box. I think this is just an early way to say 'software development' and people got caught up on their own mental images of what 'systems' are to them.

I kinda see what you mean, but systems is an exceptionally vague term. Popular use and even the formal field of Systems Science is hardly more related to computing than any other area of society. Everything programmed are systems but not all systems are programmable

I always figured it was just a shorter version of operating system programming.

Re: What Is Systems Programming, Really? (2018)

#12

Post by g42gregory »

anonymous_sorry wrote: post #9
g42gregory wrote: post #7

Perhaps from my limited AI-centric point of view, I have a simple definition of Systems Programming: when I hit enter and run Python/C/C++/Java program, what actually happens? In AI, we think of mathematical algorithms, but computers do not understand math. Math is a purely human invention, computers have no idea of math. Nor computers understand Python or C. The only things CPUs are designed to understand are 0s and…

(some other languages?) Assembly, of course. `unsafe` rust.

Rust - absolutely, for sure! In terms of Assembly, it's incredibly difficult to write an efficient Assembly code these days, especially in a multithreaded, multicore environment. In such environment, as humans we just can't compete with compilers any more. Reading and analyzing assembly code from C/C++, - sure that's absolutely necessary. Writing an assembly code from scratch, better than compiler? I am sure people do that but that's ... quite hard.

Re: What Is Systems Programming, Really? (2018)

#13

Post by lordnacho »

I think when someone says systems, they mean computer systems. So the kind of things you're interested in are ultimately computer words like drivers, memory, threads, interrupts, queues. If that's your general level of abstraction you're system programming.

Higher level languages are something like an e-commerce website. You're talking about views, orders, auth, accounting, etc. Of course they connect at some level but you're generally thinking about some business level that isn't in terms of computer words.

Re: What Is Systems Programming, Really? (2018)

#14

Post by anonymous_sorry »

g42gregory wrote: post #12
anonymous_sorry wrote: post #9

Earlier quoted context omitted.

(some other languages?) Assembly, of course. `unsafe` rust.

Rust - absolutely, for sure! In terms of Assembly, it's incredibly difficult to write an efficient Assembly code these days, especially in a multithreaded, multicore environment. In such environment, as humans we just can't compete with compilers any more. Reading and analyzing assembly code from C/C++, - sure that's absolutely necessary. Writing an assembly code from scratch, better than compiler? I am sure people d…

Yes, but there are parts of the CPU instruction set which a compiler won't ever emit. If you are using those features, as certain low-level systems must, then you use assembly (typically shortish snippets called from a compiled program).

Re: What Is Systems Programming, Really? (2018)

#15

Post by mindcrime »

To the extent that there is a real distinction between "Systems Programming" and "Whatever is not Systems Programming" and to the extent that this distinction matters, I tend to align with the take espoused in the Systems Programming[1] Wikipedia page:

The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software, are performance constrained, or both (e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications).

That is to say, the distinction I consider to be somewhat meaningful is between "Systems Programming" and "Application Programming", and I think this expresses the most salient aspect of the difference:

application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software

But is all of this terribly important? Meh. I am not convinced that it is a terribly important distinction in most day to day contexts. And that's at least partly because the lines do seem to be a bit hand-wavy, subjective, and fuzzy.

[1]: https://en.wikipedia.org/wiki/Systems_programming

Re: What Is Systems Programming, Really? (2018)

#16

Post by mibollma »

mindcrime wrote: post #15

To the extent that there is a real distinction between "Systems Programming" and "Whatever is not Systems Programming" and to the extent that this distinction matters, I tend to align with the take espoused in the Systems Programming[1] Wikipedia page: The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software whic…

My personal distinction is that application programming is more selfish, not interested in most other parallel applications whereas systems programming needs to take a more global view to ensure the system serves sufficient resources to all applications

Re: What Is Systems Programming, Really? (2018)

#17

Post by DeathArrow »

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.

Re: What Is Systems Programming, Really? (2018)

#18

Post by bluetomcat »

mindcrime wrote: post #15

To the extent that there is a real distinction between "Systems Programming" and "Whatever is not Systems Programming" and to the extent that this distinction matters, I tend to align with the take espoused in the Systems Programming[1] Wikipedia page: The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software whic…

It is a meaningful distinction. A mobile, desktop or a web app solves a problem for the end user and should be under their control via commonly-understood UI metaphores and IO mechanisms.

A systems program is a background service or a tool that provides the underlying abstractions for applications to run. An application programmer operates with well-defined APIs and, in general, should not be concerned with storage mechanisms, concurrency issues and resource management.

Re: What Is Systems Programming, Really? (2018)

#19

Post by ly3xqhl8g9 »

mindcrime wrote: post #15

To the extent that there is a real distinction between "Systems Programming" and "Whatever is not Systems Programming" and to the extent that this distinction matters, I tend to align with the take espoused in the Systems Programming[1] Wikipedia page: The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software whic…

A somewhat better dichotomy, faulty as all dichotomies, I suppose would be: No Magic Programming and Plenty of Magic Programming (or even All the Magic Programming). Where by magic one understands the expectation of the developer for the system to "just work": from the CSS developer writing a line such as `color: red;` and having no second thoughts to the browser engine developer knowing/caring about all the layers, from parsing to composition, to actually display a red colored text.

But even here, there is also a spectrum: should the browser engine developer know about the actual pixels of the display, and the "electrocoagulation of Ag nanoparticles between silicon nanostructures that support Mie resonances" [1], and so forth: the layers never stop, hence maybe it's more important actually caring about the product as a whole, in all its effects and side effects, a sort of omoiyari [2], as the Japanese would say.

[1] https://www.degruyter.com/document/doi/10.1515/nanoph-2022-0...

[2] omoiyari: 'give your thoughts and take an action on it', English: https://youtu.be/KJ5kcEQi934?t=71 Japanese: https://www.youtube.com/watch?v=16P_t4ApyhI

Re: What Is Systems Programming, Really? (2018)

#20

Post by bluetomcat »

DeathArrow wrote: post #17

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…

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.
Post reply on HN