What Is Systems Programming, Really? (2018)

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 figures behind C++, Rust, D, and Go gave radically different and unrelated answers: "client applications," "resource-constrained applications," "cloud infrastructure," and "unsafe pointer casts."

If anything, a more practical definition is "only C and C++ are systems programming languages, by fiat, because it's an artificial category whose historical roots have long since lost pertinence."

The expression is redundant isn't it? Only systems can be programmed. You can't program a cinder block or a cardboard box. I think this is just an early way to say 'software development' and people got caught up on their own mental images of what 'systems' are to them.

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.

In IBM mainframes, "systems programmer" (sysprog) traditionally means "system administrator". Part of the reason for that, is a systems programmer was expected to be accomplished at assembler, which was used to write user exits (to customise the behaviour of the operating system to meet the needs of each site) and even patches to the OS code (SYSMODs). Operators were responsible for day-to-day running of the system (startup, shutdown, mounting and unmounting tapes and removable disk packs, changing forms in printers, starting jobs, resolving minor technical problems). Sysprogs were responsible for installation, configuration, customisation, upgrades, troubleshooting more complex problems, etc. Over time, the need to customise the code of the OS declined, and IBM made the OS much harder to modify by taking away customer access to source code (IBM's 1983 "Object Code Only" announcement) – so contemporary IBM mainframe system administration involves much less programming than it used to, but the name has stuck. Also, you no longer have to write user exits in assembler – C is supported (e.g. using IBM Metal C), as is PL/X (if you work for IBM, or one of the small handful of ISVs who ordered IBM's PL/X compiler during the brief period they were offering it to them)