They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers. Instead, the burden of ensuring correctness had to be left as the cognitive burden for the developer for decades to come.

> They thought many ideas of it (see Lisp, Smalltalk) but computers where not powerful enough for complex compilers.

That's probably true for borrower-checking specifically, but I don't think it accounts for all language-design breakthroughs. There were decades between the development of functional programming languages, and widespread hybrid languages which incorporated those ideas (e.g. modern Python and C#).

See Burroughs B5500, created in 1961 with ESPOL/NEWP, 10 years before C was even an idea.

Adding slices to C would kill a lot of bugs without going all the way to rust.

> <sarcasm>Too bad those shitty engineers in the 70s didn't think of Rust...</sarcasm>

True, Rust didn't exist back then, and yes, some (few!) features in Rust weren't invented and worked out then, like the ownership model.

OTOH the corollary to that statement isn't that C was some shining beacon of good design taking advantage of the then state of the art programming language knowledge. See e.g. https://pastebin.com/UAQaWuWG

That pastebin leaves out the fact that C's spartan approach and extreme simplicity allowed C to become the most popular programming language in the world already in the time of K&R, a book still renowned for it's clarity and low mental baggage required to onboard onto a programming language.

The pastebin also left out that Bjarne Stroustrup developed C with classes, and the C, as a backward compatible superset of C to take advantage of C's unrivaled popularity.

We all can agree that the science and art behind programming language design progressed a lot in the four decades where we enjoyed C. However, it feels a kin to rewriting history to depict C as a subpar language that was poorly designed and had little to no redeeming qualities, when facts speak for themselves.

> However, it feels a kin to rewriting history to depict C as a subpar language that was poorly designed and had little to no redeeming qualities, when facts speak for themselves.

It was subpar compared to the state of the art then. It's redeeming quality was that it worked on the PDP-11, whereas the better languages required mainframe level resources. The tragedy isn't that C was invented, it fitted it's niche back then. The tragedy is that as HW evolved the world remained stuck with C rather than switching to better languages.

C was not extremely simple. Lisp was extremely simple.

Problem was, real world programming in Lisp was not simple.

Just like real world programming in C is hardly memory corruption free, and only around 10% of survey answers keep asserting to use any kind of memory assurance tooling.

The other 90% are the better than average programmers who don't need such training wheels. /s

Actually, computer science in general and the theory of programming languages in particular were already very advanced back in the 60s. It’s just people thought little of languages that would have needed gigabytes of memory (or days of run time) for the compiler to do its job.

That's exactly the point the pamphlet I linked to makes. C was far from the state of the art when it was invented, it's only major redeeming quality was that it worked on the shit low-end computers that were available to the inventors back then.

The tragedy wasn't that C was invented, it was fit for purpose then. The tragedy was that as HW evolved beyond the PDP-11 level, unix programming remained stuck at C.

Like the Go designers ignored generics, they ignored the safer systems programming languages developed as ALGOL and PL/I variants during the 60s.

https://www.bell-labs.com/usr/dmr/www/chist.html

No one can seriously argue that C's language design was inherently advantageous over, say, Pascal. If Lisp, ML, Simula, Algol, or Ada received the amount of optimization and porting investment that C did, history would be very different.

C succeeded because a.) Unix, and b.) there were a zillion platforms with a zillion different compilers that could process something like C. They all did weird things and you couldn't actually write portable code for decades, but you could kind of fake it.

That portability to a zillion platforms was part of the language design, though. 'Portable assembler' and all that.

All high level languages are portable, and many already were before C came to be.

Just marketing speak.

Sure, with more or less effort. C's semantics seem very easy to port, with very little abstraction over the commonalities that all (most?) assemblies share: computer as a giant array with a CPU and registers.

There's a gaping hole in the abstraction when it comes to word size, but that's about it, and it's obvious to diagnose at least.

Compared to the list of languages above with their more advanced features, it's super easy to port a C compiler and start compiling code. Worse is better.

So easy that to actually make C portable, UNIX had to be made into a C standard library via POSIX, otherwise portable C code is basically just logic and data structures.

Sure, but the flipside of that is that UNIX itself is fairly easy to port to a new CPU, due to being mostly written in C.

So port your compiler, figure out a syscall interface on your CPU, patch it into unix/libc and compile them, and.. it's not like that's a small amount of work but it's way easier than bootstrapping any other environment from scratch on a new architecture.

There's surely some amount of historical accident here as well, but no other language/OS combo ran on like 12 different architectures in the 80s.

Because no other timesharing OS was available in free beer source code for others to port it, it had nothing to do with C.

Actually I'd bet a dollar or two that linear threading of resources existed even before C, it just wasn't neither a common practice nor a theoretical framework at the time.