More seriously, the author makes the pretty decent point that certain classes of errors should be caught automatically. He uses buffer overflows as an example (near the bottom). I agree with his conclusion, but call out a hidden assumption. Does "automatically" include only the compiler? Of course not! We also have static analyzers, automatic test generators, and other kinds of programs that can help with this. We can and should use those, to improve correctness without either cluttering up the language or adding performance-robbing artifacts in the executable code. While it's true that C and C++ make it harder than it should be to write and use such tools, the languages and the tools need only a small nudge to improve that situation dramatically. They don't need to change their essential natures.
This "unbundling" of other language-related functionality from the compiler toolchain is an important possibility that should not be overlooked. "Do one thing and do it well" and let the user decide which things to do in which order. There are plenty of other good reasons to develop or prefer other higher-level languages. The kinds of problems the author cites are almost irrelevant.
Also I don't agree with the notion that programming is all about high level algorithms and abstraction. In the end you're programming a physical computer and you should be aware of that. In some (or even many) cases Scheme or Python or whatever (even C perhaps) may be too abstract for what you're doing, so use what's appropriate.
If there were good alternatives then maybe we can discard C. But if you want to become a professional developer you SHOULD know C, even if you dont use it regularly. The same way I believe every professional should know basic OS concepts, threads, memory management, architecture, etc.
For other majors which have require some programming it is best if they stick to something like Python, etc.
But the author does make a lot of good points regarding how many holes there are in these languages, and how much of a time sink they can. In fact I spent the last few days trying to track down this obscure bug where an object being allocated in C++ was randomly being free'd (according to gdb a valid address would become 0x1 all of a sudden) and I couldn't figure it out. I implemented some nasty WAR which makes the program run now...
In the embedded world, I would put a breakpoint on a write operation for that address. Once the breakpoint is triggered, I would inspect the trace.
Essentially here is what was happening: -Create C++ object -Try to point some reference to this object, but object address is suddenly 0x1 (just by doing one step in gdb) when trying to access one of it's properties. -Tried to run it with valgrind, and it works fine with valgrind, which leads me to believe it is some memory allocation issue with C++ on the heap -I modified the C++ class to have a uint64_t variable before the variable declaration. Now program works fine!
I believe the issue is probably with heap corruption at some point, when something overwrites certain addresses.Having that extra unneeded 64-bit int in the heap makes it still be valid.
With software engineering, there are a plethora of other tasks and checks that needs to be done before releasing it into wild. ie requirements engineering, verification, reviews etc.
