Had some illusions about the C language shattered recently.
I read an article from 2018 called C Is Not A Low Level Language from ACM Queue. The long and short of it is that C fails to get the programmer “close to the metal” in any meaningful sense because the abstract machine it uses doesn’t faithfully represent anything about modern computer architecture. Instead, it hides the complexity of modern instruction sets and memory arrangements beneath the abstractions which modeled hardware very well in the 1970s.
I, like most people, thought C was the best way to do hardware aside from just writing in assembly or machine code directly. I had assumed, but never checked, that as hardware advanced the work on C development was accounting for this; it appears backwards compatibility won out. This puts us in a weird position where both new hardware design and new C development are both constrained by trying to maintain compatibility with older C. In the case of hardware design, this means limiting the instruction sets of processors so they are comprehensible to C; in the case of C development this means an unyielding commitment to making people write code for the PDP-11 and relying ever more heavily on the compiler to do the real work.
The comments in the Reddit thread were, predictably, overwhelmingly focused on semantics of the high/low level dichotomy, with half claiming Assembler is also a high level language and the other half flatly rejecting the premise of the article or playing defense about how useful C is. I feel this kind of thing misses the point, because what I liked about C is that it helped me to think about what the machine was actually doing. Now I discover I wasn’t thinking about what the machine I was working on was doing so much as thinking about general types of things a machine is expected to do (have one processor, and memory, and disk, and IO). While this is clearly better than not knowing, it left what I thought was the core advantage in the wind.
I therefore did a search, assuming that if old faithful had failed someone else had surely tried to fill the niche. Nothing presented itself in my searches, which combined represent an hour or so of reading. Instead I learned something interesting about programming; it is entirely upward oriented. All the descriptions of every language billed as being either for embedded systems or as “one language to rule them all” advertised themselves entirely of what kind of high-level abstractions they gave access to.
Hence the old saw: dogs cannot look up; computer scientists cannot look down.
There’s Assembly for those people who actually care about what the hardware is doing. The question is whether there meaningfully can be a language who’s as low level as Assembly but which also provides higher abstractions to programmers.
Had some illusions about the C language shattered recently.
I read an article from 2018 called C Is Not A Low Level Language from ACM Queue. The long and short of it is that C fails to get the programmer “close to the metal” in any meaningful sense because the abstract machine it uses doesn’t faithfully represent anything about modern computer architecture. Instead, it hides the complexity of modern instruction sets and memory arrangements beneath the abstractions which modeled hardware very well in the 1970s.
I, like most people, thought C was the best way to do hardware aside from just writing in assembly or machine code directly. I had assumed, but never checked, that as hardware advanced the work on C development was accounting for this; it appears backwards compatibility won out. This puts us in a weird position where both new hardware design and new C development are both constrained by trying to maintain compatibility with older C. In the case of hardware design, this means limiting the instruction sets of processors so they are comprehensible to C; in the case of C development this means an unyielding commitment to making people write code for the PDP-11 and relying ever more heavily on the compiler to do the real work.
The comments in the Reddit thread were, predictably, overwhelmingly focused on semantics of the high/low level dichotomy, with half claiming Assembler is also a high level language and the other half flatly rejecting the premise of the article or playing defense about how useful C is. I feel this kind of thing misses the point, because what I liked about C is that it helped me to think about what the machine was actually doing. Now I discover I wasn’t thinking about what the machine I was working on was doing so much as thinking about general types of things a machine is expected to do (have one processor, and memory, and disk, and IO). While this is clearly better than not knowing, it left what I thought was the core advantage in the wind.
I therefore did a search, assuming that if old faithful had failed someone else had surely tried to fill the niche. Nothing presented itself in my searches, which combined represent an hour or so of reading. Instead I learned something interesting about programming; it is entirely upward oriented. All the descriptions of every language billed as being either for embedded systems or as “one language to rule them all” advertised themselves entirely of what kind of high-level abstractions they gave access to.
Hence the old saw: dogs cannot look up; computer scientists cannot look down.
There’s Assembly for those people who actually care about what the hardware is doing. The question is whether there meaningfully can be a language who’s as low level as Assembly but which also provides higher abstractions to programmers.