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

51–60 of 81 posts

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

#51

Post by jasode »

mindcrime wrote: post #48
hamilyon2 wrote: post #43

Earlier quoted context omitted.

Rabbitmq is a good counterexample. It is overwhelmingly used to provide services to other programs, deal with resource/performance constraints every second, but is an application-level program. Written in non-system programming language and not part of operating system and never will be.

It's interesting in that the RabbitMQ example helps illustrate how fuzzy and subjective this all is. Some people would definitely take the approach of "it's not part of an operating system so therefore it's not 'systems' code". Personally I would disagree. I've always considered "middleware"'ish type stuff to be "systems level" by virtue of the "it mainly provides services to other software" aspect of the definition…

>I've always considered "middleware"'ish type stuff to be "systems level" by virtue of the "it mainly provides services to other software" aspect of the definition seen above.

The middleware-programming is also systems-programming was also reinforced by Rob Pike when he originally presented Go as a "systems language". However, he now admits[1] it confused people and Go might be better categorized as a "server" apps language -- i.e. writing Google's backend infrastructure code that doesn't need to be written in C++.

In the 1980s, "systems programming" was usually a synonym for "bare metal programming" because "systems programming" was just a shorter way of saying "_operating_ systems programming". (One writes an operating system to boot up on bare metal.) And systems programming was typically assembly/C/C++ instead of business programming like COBOL or dBASE. In that mode, writing kernel drivers or a UEFI boot loader is also "systems programming". In contrast, "applications programming" was something else.

That said, if today you surveyed 100 random programmers in various domains, I'd have no idea if there's a dominant view of what systems programming is.

[1] from the article: Rob Pike: When we first announced Go, we called it a systems programming language, and I slightly regret that because a lot of people assumed it was an operating systems writing language. What we should have called it is a server writing language, which is what we really thought of it as. Now I understand that what we have is a cloud infrastructure language. Another definition of systems programming is the stuff that runs in the cloud.

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

#52

Post by arsome »

Low-level programming is definitely more meaningful, the problem is it fails the HR speak test - they tend to think it means just not very strong programming.

Basically, don't put that on your CV unless you know the company doesn't filter resumes through HR and has somewhat technical management.

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

#53

Post by cmrdporcupine »

dgb23 wrote: post #34
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…

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 componen…

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.

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

#54

Post by AnimalMuppet »

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…

To me, one difference often is how much you have available to build on. At least for some "systems programming", the answer is: Not much.

Take an OS, for instance. You can build on the other parts of the OS (if they exist yet, and/or if your layered architecture permits you to), and the bare metal. That's it. That's all you have.

Contrast that with writing an app on top of, say, a POSIX-compliant OS, and there's a huge difference in how you program. Sure, as other comments point out, there's a continuum of points between the two, but there also is a pretty stark difference between the ends of the spectrum.

Guessing a bit here, but the difference may more generally be that in application programming, you are more constrained by the logic and purpose of the application, and in systems programming, you are more constrained by the system. The app is more stand-alone, and the system is defined by the interaction of the components. From this perspective, it may be fair to think of a microservices architecture as "systems programming".

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

#55

Post by jmull »

To me, it's "system software" when it's intended to be a building block for other software.

The important implication of this is that various potentially important requirements are unknown.

Performance, load, memory, scaleability, regulatory, security, platform, CPU, etc.

If you're successful, your users (developers of apps or higher-level systems) will be using your software in ways and for purposes you can only partially know.

You have to deal with that somehow.

Maybe you can design your software to be agnostic to a concern (e.g. if your protocol uses a TCP stream, your users can adopt SSL as needed).

Maybe you optimize for the concern as much as is feasible (this is why performance is such a concern for "systems programming languages... there is no acceptable level of performance, you want the performance overhead to be as small as feasible.

Maybe you miss a concern that is important to your potential users and fail.

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

#56

Post by jmull »

eimrine wrote: post #25

As someone who speaks English poorly but has a little bit of experience with the subject, I surprised the proper name is system s programming, not system programming. Why it is so?

I think it's "systems" because it's programming components to be used to build systems, not the programming to create a particular system.

You're programming something to be used in systems.

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

#58

Post by pjmlp »

hamilyon2 wrote: post #43
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…

Rabbitmq is a good counterexample. It is overwhelmingly used to provide services to other programs, deal with resource/performance constraints every second, but is an application-level program. Written in non-system programming language and not part of operating system and never will be.

Which is quite interesting when we then talk about microkernels and hypervisor based workloads.

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

#59

Post by pjmlp »

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…

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.

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

#60

Post by jandrewrogers »

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…

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 for you.

Database engines are an excellent example of this spectrum. Some simple databases contain no systems programming at all whereas advanced databases are essentially complete operating systems that run in user space. If you walk the code bases along this spectrum, you will see a shift in the construction, character, and design of the code base as more of it transitions from "application" to "systems" code.

The distinction is important because systems programming is a different skillset than applications programming. For example, there is often a requirement to do a lot of sophisticated scheduler design that is integral to the correctness of the software in systems programming. Application programming rarely concerns itself with this, it relies on threads, locks, etc and has the OS sort out the scheduling.

Outside of actual operating systems where systems programming is unavoidable, the primary motivation to do systems programming in a user space application is it can greatly improve performance, scalability, and robustness.

Post reply on HN