Why learn C? (O'Reilly Radar)

C is in a sweet spot of minimal abstraction: enough to get portability between arm and x86 and such. Not enough to obscure what the hardware is actually doing, but enough that the "how" can get washed through somebody else's optimizer. (The old joke "C combines the flexibility of assembly language with the power of assembly language" is funny because it's true.) C lets you program close to the bare metal without having to care whether a branch delay slot is allowed to cross a cache line boundary this week, or starting all over every time somebody invents a new architecture (of which linux supports dozens: arm for phones, x86 for desktops, ppc for game consoles, mips for routers, sparc and itanic for bureaucrats, ...).

The _other_ sweet spot is up with ruby and python and lua (oh my!), scripting languages which provide thick but reliable abstractions so you can program to those abstractions without knowing how it was implementated. These languages replace pointers with references and on top of that build dynamic memory (garbage collection), and dynamic typing (duck typing), and combine them to put flexible container types into the base language. You don't have to care whether a python dictionary is a hash table or a tree under the covers; it doesn't matter, it just _works_. Scripting languages are so dynamic they do away with compilation entirely and set the executable bit on the source code: maybe they do a just-in-time bytecode compiler pass under the covers, but you can ignore it.

Between "dynamic everything with thick, opaque, reliable abstraction" and "static everything with as little abstraction as possible", you have a middle ground of "mixed static and dynamic with leaky abstractions". The worst of both worlds. Languages like C++ provide all sorts of abstractions like templates and std string types, but the implementation details intrude into the language so you have to understand how they're _implemented_ to use or debug any of them.

There's a difference between having to understand how a language feature is _used_ (ala C code) and regularly having to reverse engineer your compiler and standard template library to debug your problem (C++). In C++ you learn piles of caveats to the base language, "don't throw an exception from a constructor", "don't think you can avoid having to manually initialize every data member in your constructor with memset(this, 0, sizeof(*this));", and of course how a piece of data can live on the stack, on the heap, in the globals, in the process environment space, or be mmaped, each with its own lifetime rules. Good luck if you mix two of them in the same container through an abstraction that did an unexpected call by reference instead of call by value. For exatra fun: templates are turing complete _at_compile_time_, which means there's no way to prove a C++ compilation using templates will ever finish.

C++ never got rid of pointers, and then attempted to build elaborate abstractions on top of them. Since pointers inherently cut through abstraction (it's what they're _for_), these abstractions leak. Making the abstractions _thicker_ is painting over dry rot with more and more coats. The C++ guys keep acting like they can escape a poor foundation by building higher, that adding enough stories will render the sand underneath the whole thing irrelevant. With each new standard the language gets larger the problems with it get harder to understand and explain, which is considered progress.

C is a local peak. Scripting languages are a local peak. C++ is in the valley of suck between the peaks. Sure you can strap rocket engines to a turtle and make it work; people wrote and deployed millions of lines of Cobol and Ada code too. That doesn't make it a scalable, robust, or efficient language.

Every time a discussion of C wanders blithely into C++ as if it's the same thing, somebody doesn't know what they're talking about. And _that_ is what the above interview was about. We are teaching C++ as if that's a replacement for teaching C. It is not.