Kent Pitman's idea of "languages as political parties" [1] seems to me to offer the best perspective on the surprising reliability of C. The core community shaping C over the years has been:
1. Unix-centric, so the community has a coherent view on the preferred sort of semantics offered to users of code;
2. Applies Kernighan--Ritchie--Pike coding style that gives a clear "code smell" [2] for C code; and
3. Is the natural home of "Worse is Better", which favours source-code simplicity over specification simplicity.
For example, the "C party" favours procedures "succeeding" with non-zero exit codes on failure where other language parties have language constructs to represent failure. This can be better from the point of view of source-code simplicity, both in code and compiler, than exceptions, and worse in terms of semantics. The LK coding style, among many other C coding styles, prefers the use of goto (or sometimes setjmp/longjmp) to handle exit status [3], which is frowned upon in nearly all non-C programming language communities; the restriction of goto/longjmp to handling errors in this way avoids the problems Dijkstra pointed out [4,5], and correct usage of goto/longjmp in properly checking exit status has good code smell if generally accepted coding conventions for the use of goto to handle failure are followed.
There's a nice fragment of code illustrating the idea on SO [6].
[3]: From http://www.tux.org/lkml/: So now we come to the suggestion for replacing the goto's with C exception handlers. There are two main problems with this. The first is that C exceptions, like any other powerful abstraction, hide the costs of what is being done. They may save lines of source code, but can easily generate much more object code. Object code size is the true measure of bloat. A second problem is the difficulty in implementing C exceptions in kernel-space. This is convered in more detail below.
1. Unix-centric, so the community has a coherent view on the preferred sort of semantics offered to users of code;
2. Applies Kernighan--Ritchie--Pike coding style that gives a clear "code smell" [2] for C code; and
3. Is the natural home of "Worse is Better", which favours source-code simplicity over specification simplicity.
For example, the "C party" favours procedures "succeeding" with non-zero exit codes on failure where other language parties have language constructs to represent failure. This can be better from the point of view of source-code simplicity, both in code and compiler, than exceptions, and worse in terms of semantics. The LK coding style, among many other C coding styles, prefers the use of goto (or sometimes setjmp/longjmp) to handle exit status [3], which is frowned upon in nearly all non-C programming language communities; the restriction of goto/longjmp to handling errors in this way avoids the problems Dijkstra pointed out [4,5], and correct usage of goto/longjmp in properly checking exit status has good code smell if generally accepted coding conventions for the use of goto to handle failure are followed.
There's a nice fragment of code illustrating the idea on SO [6].
[1]: Pitman 1994, Lambda: The ultimate political party, http://www.nhplace.com/kent/PS/Lambda.html
[2]: https://en.wikipedia.org/wiki/Code_smell
[3]: From http://www.tux.org/lkml/: So now we come to the suggestion for replacing the goto's with C exception handlers. There are two main problems with this. The first is that C exceptions, like any other powerful abstraction, hide the costs of what is being done. They may save lines of source code, but can easily generate much more object code. Object code size is the true measure of bloat. A second problem is the difficulty in implementing C exceptions in kernel-space. This is convered in more detail below.
[4]: Dijkstra 1968, A case against the goto statement, http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EW...
[5]: Knuth, Structured programming with go-to statements, http://pic.plover.com/knuth-GOTO.pdf
[6]: http://stackoverflow.com/a/741517/222815