Perhaps the more significant "accident" of history, occurring before IBM-PCs with much memory got out there in large numbers, was all the vendors of 68000 based systems who didn't follow the lead of Apollo Computer and instead got a relatively cheap UNIX(TM) licence.

As PCs got more capable and more and more people were willing to program them in C---I don't remember Borland being a big player in this, in fact, it was Microsoft that produced the first really solid C compiler---the same sorts of constraints that helped birth UNIX(TM) and C were in play, until it was by and large too late to change course.

You're correct, but before Borland 'C' ( I think to directly compete with Microsoft ) much was done in Borland Pascal. Of course, much was done after as well.

I think the results of Apollo's decision speaks for itself. If something is an order of magnitude cheaper, it will propagate faster, whether it's objectively better or not.

Maybe I am a bit too much biased to Borland, but Microsoft MS-DOS compilers weren't that great, they were even the last MS-DOS compiler vendor to support C++.

They only started to have something worth buying with the 32 bit version of Visual C++ and Borland loosing their focus, until then not really.

Plenty of things on that list are better than C in key ways and pre-date Ada. Plus, many issues with C existed due to hardware limitations. The C community could've been improving the situation gradually by changing the bad features as hardware improved plus importing good things from other languages. Would've required gradual rewrites of what depended on it but would've been worth it. Or merely switching to and integrating better options like Pascal/Modula line with safety & maintenance benefits.

Instead, they continued building on the foundation of quicksand with so many systems integrity and availability lost as a result. Lost way, too easily due to developers inability to safety do common things. Things that were safe or easy in alternative languages on 1960's-1980's era hardware. Did I mention this was true in 2015 still on systems with 64 cores?

Least Stroustroup made an attempt to bring in advanced features into C. Substantially improved it in resulting quality on average but still showed how much a bad foundation hurts. Stuff like Modula-3 managed high runtime efficiency, compile time efficiency, safety, integration, and readability all at once.

So, existence of alternatives providing a better path certainly mattered. That all of it was mostly ignored taught important lessons to future people trying to improve IT. Fortunately, some learned them and now we have better stuff coming along with higher chance of adoption. Plus, significant improvements to existing stuff here and there.

"... developers inability to safely do common things."

Yep. IMO, the buck stops there.

Anyone reading CVE's for code in safer languages vs unsafe ones would disagree. The evidence would support them, too.

I'm just the wrong guy to ask about this - I know how to limit (if not eliminate) vulnerabilities, at least in what I control.

It's harder to fix culture problems with tools than we might think, in general. Perhaps future generations will look at 'C' the same way we look at open-belt farm machinery. I can't say. But the sheer volume of incumbent 'C' code bases will be around for a while.

That's honest. :) I agree it will be around a while thanks to all the incumbent code. It's why I push for efforts to automatically deal with its issues at least for legacy code. Astree Analyzer, Softbound + CETS, CHERI processor, and CompCert compiler are all top examples of that. Links below. Enjoy. :)

http://www.absint.com/astree/index.htm

http://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/

https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201503...

http://compcert.inria.fr/