Hacker News new | ask | show | jobs
by nickpsecurity 3844 days ago
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.

1 comments

"... 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/