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

41–50 of 81 posts

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

#41

Post by tony-allan »

In the IBM Mainframe world [1]:

The ABCs of IBM® z/OS® System Programming is a 13-volume collection that provides an introduction to the z/OS operating system and the hardware architecture. Whether you are a beginner or an experienced system programmer, the ABCs collection provides the information that you need to start your research into z/OS and related subjects.

...

2.1 The role of the system programmer

The role of a system programmer is broad, but essentially it is to maintain a stable operating environment for users and business applications. A system programmer’s responsibility can be at the operating system level, at the subsystem or middleware level, or at the hardware level. A system programmer installs, customizes, and maintains that environment by rolling out regular maintenance or even upgrading the entire environment to keep current and use new functions.

Another part of the system programmer’s responsibility is to provide technical support to the users of the environment. This support can be answering questions about a product or analyzing a potential defect in the product (IBM or third party).

[1] https://www.redbooks.ibm.com/abstracts/sg246981.html

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

#42

Post by kirilian »

I have a degree in systems programming (BSc). So at least some people thought of systems programming as consisting of:

* Lots of pretty low level programming. OS level stuff and raw network programming.

* Low level database and data storage skills in all levels. Programming, database internals like optimizers and storage engines.

* All aspects of networking; TCP/IP, other protocols, physical level, routing protocols and lots of socket level programming in Unix.

* Operating system internals.

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

#43

Post by hamilyon2 »

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.

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

#44

Post by [deleted] »

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…

[deleted]

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

#45

Post by zamnos »

swinglock wrote: post #38
CodeArtisan wrote: post #32

Earlier quoted context omitted.

>Other programmers are users too. System programming is about a program being used by another program unlike an application which is being used by a person. A programmer too will not use that program but use an application to develop a program which will then use that program. This makes system programming distinct from application programming in purpose, philosophy and reality.

What's the significant difference between having users, and having a chain of users, in purpose, philosophy and reality?

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 interacts with. Its purpose is dependant on its relationship to the user. The philosophy is that the user could click on anything on the screen at any time, so the program had better be ready! The reality is that users live in their own world, free from all concerns of the silicon world, except one - power. They may perceive memory pressure in the form of slowness, but they don't feel it the way the operating system does.

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

#47

Post by tkiolp4 »

The difference is that Systems programmers believe they are better (i.e., more skilled) than Applications programmers. Just like infrastructure engineers think they are better than backend engineers think they are better than fronted engineers think they are better than designers.

Of course this is a generalization, but holds surprisingly true.

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

#48

Post by mindcrime »

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.

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 seen above.

Web browsers are another interesting item that don't fit neatly into this classification either. I mean clearly a browser is something that provides services directly to the user. You use it to navigate the web, view and download documents, store bookmarks, and all sorts of stuff. It's 100% "application level." Except... the browser also provides a runtime, including memory and process management, networking services, graphical rendering, etc. to other software. In fact, a browser is basically a poor man's Operating System. So it's 100% "systems level." Wait, what?!??

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

#49

Post by zamnos »

IshKebab wrote: post #36
bluetomcat wrote: post #18

Earlier quoted context omitted.

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

It's still a continuum, not distinct categories. People can't deal with that, and given the fact that there is really zero point talking about this continuum (it's not even in job titles) I would say we should just ditch the term "systems programming" entirely.

Kubernetes is clearly a different sort of program compared to Microsoft Word. Even if we don't have a rigorous ontology that sorts them into two distinct boxes neatly, they're just so different at the extremes that it's useful. We make a distinction between pulmonologists and cardiologists even though they both know anatomy and deal with the human body, and as we mature as a discipline, specialization is only natural. Denoting the area someone works in as belonging to one group or another is useful for determining peers that share your concerns, vs people that work in totally different areas from you. That doesn't make them better or worse than you, just different.

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

#50

Post by lenzm »

ly3xqhl8g9 wrote: post #19
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,…

I think this is a different dichotomy - declarative vs imperative. Generally, the declarative languages have all the magic implemented in an imperative engine.
Post reply on HN