There is always Assembly, compiler extensions, or OS specific APIs, as part of the deliverable.
Funny how UNIX folks always have these two weights approach.
I beg to differ in wax quality for candles, but if we get to do juice with bitter lemons, so be it.
At least is refreshing during Summer.
K&R C has separate compilation, pointer casting, a usable but janky and bug-prone variable-length string type, variadic functions, static variables, literal data of array and record types, bitwise operations, a filesystem access API, and an array iterator type. None of those require "assembly, compiler extensions, or OS specific APIs." (Well, I'm not sure if they specified variadic functions in the book. The first ANSI C did.)
Jensen & Wirth Pascal has none of those, making it completely inadequate for anything beyond classroom use, which was what it was designed for.
Each Pascal implementation that was used for systems programming did of course add all of these features, but many of them added them in incompatible ways, with the result that, for example, TeX had to implement its own string type (in WEB).
Take all the Assembly routines from libc, and K&R C turns into a macro assembler with nicer syntax. And not a good one, given that real macro assemblers actually have better macro capabilities, alongside their high level constructs.
Quite visible in the C dialects that were actually available outside UNIX, on computers people could afford, like the RatC (Made availalbe via A book on C) and Small-C (DDJ article series).
Well even dumbest standard pascal compilers like GPC do allow calling into Assembly. So it should count for Pascal as well, if that is the measure.
Then we have this thing sticking with ISO Pascal from and its dialects, always ignoring that this was seen as an issue, that that is why Modula-2 exists since 1978, and Extended Pascal since 1991, one year later after ANSI C (C89 got a short C90 revision fix).
Also following the K&R C alongside Assembly line, several companies were quite successful with Pascal dialect alongside Assembly, including a famous fruit company.
Back in 2024, C extensions keep being celebrated to the point the most famous UNIX clone can only be compiled with a specific compiler, and the second alternative is only possible after a search company has burned lots of money making it possible.
But hey, lets stick to Pascal and its dialects.
I think "a macro assembler with nicer syntax" is an excellent summary of C. Though it's transitioning to "a retrocomputing programming language we have to support in order to be able to run software that was written long ago".
I agree that many other macro assemblers have more powerful macro capabilities than C. After looking at most of the output of the group that produced Unix, I think that's on purpose: cpp was deliberately less powerful than GPM or m6, but that's not because they weren't familiar with m6 or couldn't figure out how to write it, and ed was deliberately less powerful than QED or TECO, but that wasn't because they weren't familiar with QED. Possibly Plauger's remark about how one of the worst things he'd done in his life was to write a relocating linker in QED provides a clue as to why.
With the benefit of 45–55 years of hindsight, the decision to prioritize clarity over expressiveness in ed and cpp seems to have really paid off. You seem to disagree, but you don't say why; maybe you think it's axiomatic that more expressive languages are better, despite the fact that we're having this discussion in HTML rather than PostScript or TeX, using URLs rather than Smalltalk or Open Firmware bytecode packets, with browsers written mostly in C++ rather than Scheme or Common Lisp, over TCP/IP rather than CHAOSNET. If my suggested axiom were correct, all of those would be the other way around.
I'd like to see RatC, but I haven't been able to find old editions of A Book on C, and the later revisions seem to have removed it.
I don't see how Modula-2 is relevant to a discussion about Pascal. There were lots of Pascal-inspired languages in the 70s and 80s; Modula-2 was neither the most influential one nor Wirth's favorite.
It remains true that you could easily do portable systems programming in C in the late 70s and 80s, and you could do nonportable systems programming in VAX Pascal, but doing portable systems programming in Pascal required major compromises when it was possible at all. (Just to clarify, when I say "systems" I don't mean "kernels"; I mean "not applications", as you clearly also did when you said "VMS also supported Pascal and BASIC dialects for systems programming.")
There were other parts of your comment I wasn't able to make any sense of, but if you feel you said something I haven't responded to, please feel free to clarify.
