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

71–80 of 81 posts

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

#71

Post by vitiral »

david2ndaccount wrote: post #5

Ultimately, the author comes to a dubious conclusion by ignoring the context. By studying what people were writing about in the 70s, he also ignores the context - it was a given that any program of significant size or of a fundamental nature would compile (efficiently) to machine code. The hardware was too weak to support anything else. A language that didn’t satisfy certain performance criteria wouldn’t even be a co…

His odd conclusion being that ML languages like Haskell are "systems programming." I thought the rest of the article was mostly interesting, but how that could possibly be your conclusion is a bizzare mystery. My guess is he wrote the conclusion before the research and got the cart before the horse.

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

#72

Post by jandrewrogers »

oscillonoscope wrote: post #65
jandrewrogers wrote: post #60

Earlier quoted context omitted.

In practice, the demarcation line for "systems programming" is when the software directly controls and manages the hardware resources it uses. Software like this takes on some of the characteristics of an operating system because it is required to provide similar functionality, even if not an operating system per se . In application code, some other piece of software, usually the operating system, takes care of this…

Under your definition, would embedded programming fall under systems programming or do you see them as distinct areas?

I think embedded is a distinct subset of systems programming. It definitely deals with hardware resource management, but is a bit different because it tends not to build the high-level resource management abstractions on top of the hardware for other application code to use e.g. what a database kernel is to a database.

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

#73

Post by marcosdumay »

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…

> whereas systems programming aims to produce software and software platforms which provide services to other software

We have the word "middleware" to describe that.

If you look how the word is used, "systems programming" does clearly not mean that (personally, I don't remember ever seeing it used that way). It's more used as an architecture paradigm, where you don't expect a lot of things to be abstracted, for whatever reason. The word choice is obviously because the underlining system that provides those abstractions is architected this way.

The distinction is actually relevant in a lot of contexts. As we get better languages and compilers that provide lower cost or more expressive abstractions, it is getting less and less relevant, but it still has a lot of relevance. And yes, it's a fuzzy concept like any other software architecture one.

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

#74

Post by layer8 »

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…

Well, arguably any library provides services to other software and not directly to the user. The definition needs to be more specific than that. Is implementing left-pad systems programming?

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

#75

Post by Jiocus »

namaria wrote: post #8
Jiocus wrote: post #6

Earlier quoted context omitted.

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

>but systems is an exceptionally vague term. I don't understand the use of but here. This doesn't contrast with what I said. >Everything programmed are systems Then 'systems programming' is a redundant turn of phrase. You don't say you're 'food cooking', while there are foods you don't cook.

> I don't understand the use of but here. This doesn't contrast with what I said.

I meant that I don't agree with your sense of the word 'system', as clearly and obviously referring to software development. Of ourse, if paired up with the words 'development' or 'programming', the association is there.

Still, the following titles reads to me as very different occupations:

- Systems Programmer (low-level, bare metal)

- Systems Engineer, (e.g. aeronautics, robotics, banking, requirements)

- Systems Developer (business domains, processes & people, services)

biases all mine

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

#76

Post by zamnos »

swinglock wrote: post #62
zamnos wrote: post #45

Earlier quoted context omitted.

if we simplify it to being an OS (systems) vs a gui (applications) programs, we can see their purpose, philosophy, and reality. The OS' purpose is to run other programs, and thus that interface, Elf, is full of technical implementation details fitting the philosophy of a OS that allows multiple processes to run, and reality - Linux (OS) does not compete with Airbnb (application). Contrast this to a GUI program a user…

This appears both incomprehensible and wrong, but let me check if I understood. Systems: - Lacks a GUI. - There are technical details. - Doesn't compete with applications. - Memory pressure is an issue. Applications: - Has a GUI. - Need to be responsive. - Power usage is important. - Memory pressure results in slowness. I don't think we got any closer to a useful answer.

It can't have been that incomprehensible if you got that much out of it, but I mean if you're going to call me wrong, what's your take?

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

#77

Post by swinglock »

zamnos wrote: post #76
swinglock wrote: post #62

Earlier quoted context omitted.

This appears both incomprehensible and wrong, but let me check if I understood. Systems: - Lacks a GUI. - There are technical details. - Doesn't compete with applications. - Memory pressure is an issue. Applications: - Has a GUI. - Need to be responsive. - Power usage is important. - Memory pressure results in slowness. I don't think we got any closer to a useful answer.

It can't have been that incomprehensible if you got that much out of it, but I mean if you're going to call me wrong, what's your take?

I don't think there's a significant difference and I don't see the importance of making the distinction.

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

#78

Post by fsckboy »

legerdemain wrote: post #2

Will makes a dubious claim to support a dubious distinction. Plenty of large, complex infrastructure is written in Python. > Dynamic programming languages are arguably still far from systems languages, > since dynamic types and idioms like “ask forgiveness, not permission” are not > conducive for good code quality. I find it amusing that, when asked to give a defining characteristic of systems programming, key figure…

I liked much of your critique, but you completely lost me with your last para.

Systems programming is about adjudicating contention for system-constraints and system constrained resources. It's about creating relatively clean interfaces to relatively thorny problems. It's only lost apparent pertinance because of the explosion in numbers of people "coding" web front ends or other things at the top of the stack, and because the code that solves some of these problems is well understood and complete. But underneath all what we do in the various userspaces is the same and even greater complexity of problems which require maintenance and development/porting to new architectures as they get developed

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

#79

Post by ungamedplayer »

amelius wrote: post #24
bluetomcat wrote: post #20

Earlier quoted context omitted.

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.

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.

Assembly as a language meets all of these requirements. Is there an exception that assembly of some type doesn't meet ?

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

#80

Post by agumonkey »

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…

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