> C is different and I would argue that it has prevailed because it is more closer to the metal.
It prevailed because it was married with an OS (UNIX) that spread into the enterprise.
History proves that system programming languages only survive when they are married with an OS and are the only supported language(s) in the OS vendors SDK.
There wasn't nothing in C that couldn't be done in then existing Pascal dialects.
Unix is amazing, and C certainly rode along with Unix. But I do think C being closer to the metal is what made it popular. Unix has become widespread, but PC's spread faster sooner (giving Linux a place to land), and what made PC's spread was software. Writing C was easier and faster than writing assembler, while still being close enough to the metal to be a substitute.
It has quite a good design decisions, but I consider that adjective for Xerox PARC systems, specially Mesa/Cedar.
> But I do think C being closer to the metal is what made it popular.
I keep hearing this from C proponents, yet I never found a use case where C dialects (this was before standards were widespread) offered more close to the metal features than Pascal dialects or other system programming languages for that matter.
Every time I ask a C code to tell me a closer to the metal feature other system programming language compilers lack, I come out empty handed.
Just to confirm this: Turbo Pascal (at least the versions I had contact with) allowed for inline assembler and (as I read on Wikipedia page) machine code. You can't get much "closer to the metal" than this.
Allowing inline assembler is not the same thing as the language being close to the metal. Close to the metal means staying within the language but still having the power to do the same things as pure assembler.
If that is the definition, than C surely isn't close to the metal, specially since intrisics, function modifiers and inline assembler are not part of the standard.
I'd say it differently. "Close to the metal" means the language constructs correspond to ASM constructs. E.g. PL/M 86 (an early Intel language for the 8086) had something like pointers (based variables) that corresponded exactly to the addressing modes of the machine code. Their data types corresponded to register widths available. They had a string-move intrinsic that was exactly REPNZ MOVSB etc.
Yeah...Mesa/Cedar are excellent examples of how to extend Pascal to create a really first rate systems programming language. Similar with the PERQ extended Pascal used to write POS. And of course the Modula->Ada line are are pretty decent to outstanding systems programming languages.
> Pascal dialects
This is, of course, the important point. The 1974 Wirth defined version of Pascal was pretty crappy, or at least limited, as a systems language and even the 83 ISO standard didn't much change that. However, the variations and extensions that emerged fixed those shortcomings pretty fast, to the extent that Kernigans paper was almost out of date wrt "contemporary" Pascal when it was published.
It prevailed because it was married with an OS (UNIX) that spread into the enterprise.
History proves that system programming languages only survive when they are married with an OS and are the only supported language(s) in the OS vendors SDK.
There wasn't nothing in C that couldn't be done in then existing Pascal dialects.