50 years of C, the good, the bad and the ugly [video]

> that’s pretty much it.

Only if you ignore

1. variadic arguments as in printf,

2. function pointers which are a very elementary (type-unsafe) form of closures,

3. a nice way of casting to void

4. setjmp and longjmp goodies (?) which allow you to code up co-routine libraries and exception handling mechanisms

I'm sure there are more such facets I am missing.

The elegance of the specification may be questionable, but the scope of what C tried to achieve is breathtaking. It actually is superior to most of its improvements.

I bought a C compiler at my job in 1984 because I thought it was the future, then spent nearly a decade writing MacOS apps in C. I even added object extensions to it (for our use) in 1989 because C++ was not an option yet.

I worked with Objective-C in the late 90s and again in the 2010s, which is basically C with funky object stuff.

I don't miss it at all. C is very low level and so easy to write bad code in if you don't have solid discipline, the language doesn't help at all, which was not really a design decision back then. The first C compiler we used didn't even support prototypes.

I exclusively use Swift now.

The C language and the C stdlib are not the same things. You can use C without the stdlib.

You simply have to build or use a different framework offering similar or better APIs.

There is no elegance there. Casting to void is not a plus. That’s just C having no proper type system.

Function pointers as an elementary form of closures, come on, what’s next? Closures are defined by capture. It’s nearly as fun as pretending C as coroutines because of setjmp.

How can a statement like C being semantically poor even be seen as controversial? For god sake, we are talking about a language which semantically doesn’t even have proper arrays.

> The elegance of the specification may be questionable, but the scope of what C tried to achieve is breathtaking. It actually is superior to most of its improvements.

Seriously? It wasn’t even a good language when it was released. Lisp and Pascal were far better. It won because of compiler availability and adequate performance on limited platforms.

HN really is a joke sometimes.

My prediction is that C will die off as a language long before Fortran and COBOL. What keeps a language like Fortran alive is that it is used in an application niche where rewriting is done at best ship-of-Theseus style, and the friction of using a new language for a component far outweighs the benefits of doing so (weather models are a good example here). For COBOL, it remains in applications where the cost of a switch or rewrite includes a low risk of catastrophic, and therefore expensive, failure (see Southwest Airlines for a very public and recent example of such a failure).

C does have a similar kind of niche at first glance: systems programming is of course conservative, rewriting everything is unlikely, and of course, C is the language used for ABI. Except on closer inspection, that moat is remarkably shallow. Being the language of ABI means that every competitor language has some way to speak C guaranteed, so the friction of rewriting systems software Ship-of-Theseus-style is much lower (though still nonzero). Systems software is rewritten from scratch on a much higher cadence: in the last 20 years or so, most of the userspace system glue for Linux has been replaced (e.g., systemd, iproute2, pulseaudio, wayland). And we've learned over the past few decades that there's no practical way to fix C's fundamental unsafety issues with software engineering practices, and C's committee is too conservative to consider retrofitting the necessary features to be able to fix unsafety at a language level (to say nothing of getting people to use it).

There is already a small clutch of languages that can serve C's niches that don't have the same fundamental unsafety issues, and right now, we're sort of at an experimental stage of system software trying them out. It's not unreasonable to believe that within a decade or so, one or more of these languages would be considered a standard, safe choice for implementing new systems software--and the use of C in new projects will start dropping. At some point, the proliferation of non-C systems projects will make people point out that having these components talk through C's ABI is too limited in functionality, and a system will change its ABI from C to some other language. And once it is no longer the language of ABI, C will lack its moat that keeps it alive, and it will start dying, though its death will be a slow, agonizing death.