Live data from Hacker News

What Is Systems Programming, Really? (2018)

willcrichton.net

31–40 of 81 posts

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

#31
I'm surprised to see a complete lack of application of the OSI model to answering this question.

Systems programming is what happens when you apply the OSI model to the interconnections required for you to have a happy user, using your application.

Oh, that's too simple, I hear you say! Not at all. The model just gives you the harness you need to grasp the complexity.

If you're not "OSI ALL THE THINGS!" you didn't quite get the memo that the network is the computer, and thus "ALL THINGS ARE OSI'able!"

The model was developed during the network era, but has been discovered broadly through wide application that it is applicable to all systems interconnection.

https://en.wikipedia.org/wiki/OSI_model

When you traverse the OSI layers successfully, identifying and creating the components relevant to the layer interconnects, you are a systems programmer.

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

#32

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…

Every software has a user. Other programmers are users too. In addition, all software is performance constrained, as no user has an infinitely fast computer or infinite time. Of course it's fuzzy and unimportant, they're just words for categories we've made up, and didn't even make a very good job of it. Even if we did make it clear which is which, what's the gain from being able to make a clear distinction? Is it an…

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

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

#33

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…

Every software has a user. Other programmers are users too. In addition, all software is performance constrained, as no user has an infinitely fast computer or infinite time. Of course it's fuzzy and unimportant, they're just words for categories we've made up, and didn't even make a very good job of it. Even if we did make it clear which is which, what's the gain from being able to make a clear distinction? Is it an…

The distinction goes to use case, and helps the hammer and nail programmers not get into arguments with the screwdriver and screws programmers over which is better - a hammer or a screwdriver? Of course, we as an industry love to argue, but I do think there is some use in having a distinction. Systems programmers have other programmers as users, application programmers have people as users. B2B vs B2C.

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

#34

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

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

#36

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

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

#37
post #33

Earlier quoted context omitted.

Every software has a user. Other programmers are users too. In addition, all software is performance constrained, as no user has an infinitely fast computer or infinite time. Of course it's fuzzy and unimportant, they're just words for categories we've made up, and didn't even make a very good job of it. Even if we did make it clear which is which, what's the gain from being able to make a clear distinction? Is it an…

The distinction goes to use case, and helps the hammer and nail programmers not get into arguments with the screwdriver and screws programmers over which is better - a hammer or a screwdriver? Of course, we as an industry love to argue, but I do think there is some use in having a distinction. Systems programmers have other programmers as users, application programmers have people as users. B2B vs B2C.

Got it. Businesses heavily employing a B2C marketing strategy should employ Python, Java and JavaScript programmers, while the B2B equivalents should use C and C++. Very useful to be able to make these decisions on a higher level, so that programmers don't need to argue about which tools would be well suited for a particular product. Allowing sales to make these decisions for us will improve our time to market.

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

#38

Earlier quoted context omitted.

Every software has a user. Other programmers are users too. In addition, all software is performance constrained, as no user has an infinitely fast computer or infinite time. Of course it's fuzzy and unimportant, they're just words for categories we've made up, and didn't even make a very good job of it. Even if we did make it clear which is which, what's the gain from being able to make a clear distinction? Is it an…

>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?

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

#39

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

Or Copy-Pastable from StackOverflow Programming and Not-So-Copy-Pastable from StackOverflow Programming?

Just brainstorming here xD.

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

#40

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?

UX?
Post reply on HN