Hacker News Reader

Comment by swinglock | Hacker News Reader

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 any more productive than fighting over who got the best text editor?

View on HN

Even if we did make it clear which is which, what's the gain from being able to make a clear distinction?

Exactly. I mean, what will you do differently at work tomorrow if your job title is changed from "Systems Programmer" to "Application Programmer"? Approximately nothing.

Is it any more productive than fighting over who got the best text editor?

The text editor discussion is probably more productive!

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

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.

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.

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.

Reply on news.ycombinator.com