[cdumler]

> C was created to rewrite UNIX from its original Assembly implementation

I don't think I can go with that one. C was created in the same period as people were trying to find a way to create a common platform, but C was more about trying to solve the problem of having a higher-level language that wasn't available for the low-end hardware (ie PDP-11, etc) of the time. Richie wasn't trying to reinvent the wheel.

He would have been happy to use other languages, but they were either design for large platforms which needed more resources (Fortran) or looking to be locked behind companies (IBM's PL/I). Richie considered BCPL, which at the time had a design that made it pretty easy to port if your computer was word-based (same size of bit-width for all numbers regardless of purpose). But, mini-frames were moving towards byte-based data and word or multi-word-based addressing. Plus, mini-frames had poorer hardware to make it cheaper, so typing on them meant more physical work.

A lot of UNIX design came from trying to use less: less memory, less paper, less typing. Richie tried to simplify BCPL to be less wordy by making B, but ultimately decided to jump to the next thing by making a language that would require as few keystroke as possible. That's why C is so symbolic: what is the least amount of typing to perform the concept? That made it pretty easy to translate to a fixed set assembly instructions; however, it hasn't had a symbiotic relationship with assembly.

If anything, it is the reverse. Just look at the compiler for all of the memory addressing it has to know. Look at any reasonably complex program of all of the compiler directives to see all the platform exceptions. C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment? I left C++ a long time ago because I could take code that would compile on two different platforms and result in totally different behavior.

I think all of this drama has to do with the simple fact of there a bunch of people content to live in a one-langauge dominated environment and the head of Linux doesn't want to decide if that is or isn't the mandate; however, by not taking sides, he has effectively taken the one-language mandate. Rust needs to reimplement Linux.

[tsimionescu]

> C++ really took failure modes to the next level. My favorites is "a = b/*c;" Is that "a equals b divided by value pointed at by c" or "a equals b" with a comment?

That is a really bizarre comment, especially including a comment that is perfectly valid K&R C, and just as "ambiguous" in that. The answer is of course that it is an assignment of the value b to a variable called a, followed by a comment. "/*" is always the start of a block comment.

Since C99 (and since forever in C++) there is also the new style comment, //, for commenting out the rest of the line, and this in fact broke certain older C programs (`a = b//* my comment*/ c;` used to mean a = b / c; in C89, and means `a = b` in C++ or C99).

[int_19h]

Well, it is kinda weird to take what would otherwise be perfectly legitimate and meaningful syntax and make it a comment. E.g. Pascal uses (* *) instead, and there's no other construct in the language where those can legitimately appear in this order.

[tsimionescu]

Sure, but it's still a choice that C made, long before C++, so it's bizarre to see it in reference to how much worse C++ is.

As for the actual syntax itself, I do wonder why they didn't use ## or #{ }# or something similar, since # was only being used for the preprocessor, whereas / and * were much more common.

[int_19h]

/* */ is a PL/I thing that somehow ended up in B. I suspect that Ritchie just wanted multiline comments (which BCPL didn't have - it only had // line comments), and just grabbed the syntax from another language he was familiar with without much consideration.

Or maybe he just didn't care about having to use whitespace to disambiguate. The other piece of similarly ambiguous syntax in B is the compound assignment, which was =+ =- =* =/ rather than the more familiar C-style += etc. So a=+a and a= +a would have different meaning.

[pjmlp]

That is the usual cargo cult story of C, systems programming languages go back to JOVIAL in 1958, NEWP in 1961, one of the first systems programming languages with intrinsics and unsafe code blocks.

You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.

There is enough material that show had UNIX been a commercial product instead of free beer source code, most likely C would have been just another systems language in the mysts of time.

[doug-moen]

> You surely aren't advocating that hardware predating PDP-11 for a decade are more powerful.

That's correct. The PDP-11 used for the first Unix system had 24KBytes of memory, and no virtual memory. The kernel and the current running process had to both fit in 24KB. This PDP-11 minicomputer was vastly underpowered compared to ten year old mainframes (but was also far less expensive). The ability of Unix to run on such underpowered (and cheap) machines was a factor in its early popularity.

BCPL was first implemented on an IBM 7094 running CTSS at Project Mac at MIT. This was one of the most powerful mainframes of its era. It had 12× the memory of the Unix group’s PDP-11, plus memory protection to separate kernel memory from user memory. One of the historical papers about C noted that a BCPL compiler could not be made to run on the PDP-11 because it needed too much memory. It needed to keep the entire parse tree of a function in memory while generating code for that function. C was designed so that machine code could be generated one statement at a time while parsing a function.