Also, I don’t think we’re going to see any new CPU architectures (x86 or Arm) or OSs being developed, and all major current OSs (Unix, Windows) have a C-based API. So C will probably always be the first class citizen for OS work. (Where always means at least 20 more years. :-) )

But C has clearly lost ground in the application programming space, where VB/Java/C# rule, and in the client side of web apps, where JavaScript rules. (And if you consider C-based system programming error prone, wait until you try developing AJAX/ATLAS style programs!)

P.S. I am interested in some of these wacky French programmed-proof systems, like the verifiably correct C compiler that the Coq project is working on. I would like to have a compiler that was known to be correct. If only it didn’t typically take eight times as much code to prove a system correct as to write the system in the first place.

Admittedly, C doesn’t provide the higher level abstractions and doesn’t really supply a way to create domain specific languages with ease (for example, somebody mentioned the language understanding paging above). If you need to create a DSL, you are basically as restricted as you are in Java, which leads to fooling the type system (void* anyone) or making a bunch of XML documents.

I think we still use C because we have a large amount of existing C code, it’s really fast (particularly compared to the languages implemented in it), everybody who learned CS in school is at some point forced to learn about pointers, as they are the basis for all kinds of other artifacts in the higher level languages. This is kind of like asking “why do we still use gasoline?” The answer is that everybody is used to it, consumers, mechanics, car companies, oil companies, national politics, et cetera. If you make a fundamental system change, everyone will have to be reeducated. I am not saying it is impossible, I am just saying it is a big task.

In that case you need a language whose syntax, semantics and runtime all match the architecture to which you code.

I’ve got a pet kernel whose virtual memory manager has had too many bugs for ages, so I’d love a language that inherently understood what page tables, segments and descriptor tables are, and how to check them for validity! However, this language would be stuck firmly on my x86 processor. It would limit the portability of my kernel in addition to its own. Yikes.

We use C and Object Pascal as compromises: low-level enough that a smart human can take the time and write useful systems code without the language’s ideas about theory of computation getting in the way, but high enough that doing so takes months instead of years.

A Lisp operating system worked on Lisp machines where the language matched the architecture. C still reasonably approximates the resources available to a kernel programmer at boot when the kernel knows nothing about the hardware it runs on and has no hardware resources of which to speak.

I have a rant in progress about this….

Oh boy.  In the early 80s I was in love with LISP machines (made a pilgrammage to MIT to visit my friend Jack and to see the LMs on the 9th floor). Wonderful things, but evolutionary Do-do birds as soon as stock hardware got fast enough (I’m going to have to crank up a CADR emulator some time).

I’ve written tons of code in Object Pascal. Thanks, no. This was in the late 80s and early 90s on the Macintosh. My experience with Pascal-like languages is that you generally lie to the type system about as much as you lie in C.  The languages are really equivalent.  You’re doing the same things, with “semicolons in different places.” I believe that Object Pascal has non-”duck”-types, which are stronger, yes, but I think not the whole story.  Again, things like having stale objects around, getting interfaces out of sync and screwing up your environmental rules are equally possible. O-P is not a panacea.

More, when the toddler is asleep… :-)

C is used for those purposes today because the OS and libraries they run on are written in C, and because hardware is optimized for C’s execution model, not because of any inherent superiority for such tasks.

The only downside is that you have to write a minimal Run-Time Library for bare metal. I can send you mine, if you like, but several are already on the Free Pascal unit contributions page.