Name: Connoisseur 2010-08-21 19:15
Abstract: Systems languages are not those designed for embedded development, but rather those intended for writing applications, such as dæmons and compilers.
There are a lot of stupid threads on /prog/ this year. In these threads I see people using the term "systems programming" to refer to embedded development. This is wrong and the people doing this should reread SICP. If they don't know how to read SICP, then they could at least read Ousterhout's article on scripting languages, where he explains that term and its antonym in a clear, authoritative tone.
The key to understanding the systems-versus-scripting distinction is to consider it in its original context in the culture of big iron developers. UNIX makes it especially clear, with examples you should all be familiar with (page 88 of the field manual). A scripting language is a language such as
Here's the mind-blowing part: Both systems languages and scripting languages are supposed to be high-level languages.
It doesn't take fucking Einstein to deduce that scripting languages are generally higher level than systems languages, but nothing dictates that a systems language has to be as low level as an assembler language with a couple of macros and a kindergarten-quality type system. In the 1970s, computing power on the whole was such that this was the most productive design for C, but even then, the concept of a systems language did not necessitate this design.
In the age of GUIs and desktop computers, a more modern (and more intuitive) name for "systems programming" is "applications programming." However, this does not mean that you get to repurpose the older term for some ad-hoc superset of real-time and/or embedded development. Instead you should use the terms "real-time" and "embedded" when you mean "real-time" and "embedded" respectively. Oh, and the definitions of these terms are not intuitive. If you don't know what they actually mean, read SICP. If you can't provide a rigorous definition of them from memory, you definitely need to read SICP about a million times, and then do some kernel programming. Kernel programming is hard as fuck, and requires intimate, even biblical knowledge of real-time programming. Writing drivers requires a deep and magical understanding of embedded programming and sometimes also an understanding of real-time programming, insomuch as these concepts are not entirely mutually intelligible.
If you do not need direct hardware access for the purposes of desperately platform-dependent voodoo, but you still need serious performance, then that's systems programming (applications programming). If you are not doing real-time development, garbage collection is perfectly acceptable.
Common Lisp and Haskell are systems languages. Go is certainly a systems language. Even Java is a systems language, assuming your platform is the JVM. Python is not a systems language, and anyone trying to use it as one will quickly find himself rewriting half the code in C.
By today's standards, with a post-Rails understanding of the term "high-level language," C is inferior as a systems language. However, it is still totally adequate as a real-time and embedded language. If one were to uninvent C, one would first have to create a superior real-time language and a superior (portable) embedded language. (These do not necessarily have to be the same language.)
If you get nothing else out of this post, you should at least have arrived at the conclusion that "systems language" is a bad and misleading term that everyone should stop using. Mind you, Rob Pike is very fond of this terminology and a mere insect like you cannot hope to change his mind. But maybe you can convince reddit to do it for you.
Actually, this would be basically awesome. Basically.
There are a lot of stupid threads on /prog/ this year. In these threads I see people using the term "systems programming" to refer to embedded development. This is wrong and the people doing this should reread SICP. If they don't know how to read SICP, then they could at least read Ousterhout's article on scripting languages, where he explains that term and its antonym in a clear, authoritative tone.
The key to understanding the systems-versus-scripting distinction is to consider it in its original context in the culture of big iron developers. UNIX makes it especially clear, with examples you should all be familiar with (page 88 of the field manual). A scripting language is a language such as
sh or Perl, designed to serve as a high-level front end to the vocabulary of libraries and executable commands on a system. A systems language is a language in which these libraries and executable commands are implemented.Here's the mind-blowing part: Both systems languages and scripting languages are supposed to be high-level languages.
It doesn't take fucking Einstein to deduce that scripting languages are generally higher level than systems languages, but nothing dictates that a systems language has to be as low level as an assembler language with a couple of macros and a kindergarten-quality type system. In the 1970s, computing power on the whole was such that this was the most productive design for C, but even then, the concept of a systems language did not necessitate this design.
In the age of GUIs and desktop computers, a more modern (and more intuitive) name for "systems programming" is "applications programming." However, this does not mean that you get to repurpose the older term for some ad-hoc superset of real-time and/or embedded development. Instead you should use the terms "real-time" and "embedded" when you mean "real-time" and "embedded" respectively. Oh, and the definitions of these terms are not intuitive. If you don't know what they actually mean, read SICP. If you can't provide a rigorous definition of them from memory, you definitely need to read SICP about a million times, and then do some kernel programming. Kernel programming is hard as fuck, and requires intimate, even biblical knowledge of real-time programming. Writing drivers requires a deep and magical understanding of embedded programming and sometimes also an understanding of real-time programming, insomuch as these concepts are not entirely mutually intelligible.
If you do not need direct hardware access for the purposes of desperately platform-dependent voodoo, but you still need serious performance, then that's systems programming (applications programming). If you are not doing real-time development, garbage collection is perfectly acceptable.
Common Lisp and Haskell are systems languages. Go is certainly a systems language. Even Java is a systems language, assuming your platform is the JVM. Python is not a systems language, and anyone trying to use it as one will quickly find himself rewriting half the code in C.
By today's standards, with a post-Rails understanding of the term "high-level language," C is inferior as a systems language. However, it is still totally adequate as a real-time and embedded language. If one were to uninvent C, one would first have to create a superior real-time language and a superior (portable) embedded language. (These do not necessarily have to be the same language.)
If you get nothing else out of this post, you should at least have arrived at the conclusion that "systems language" is a bad and misleading term that everyone should stop using. Mind you, Rob Pike is very fond of this terminology and a mere insect like you cannot hope to change his mind. But maybe you can convince reddit to do it for you.
Actually, this would be basically awesome. Basically.