This is the fifth of a series of articles examining Bjarne Stroustrup’s writings about the core foundations in C++. The first part is here with links to the other parts:
Checking and Helping Programmers to get things Right
“For this reason restricting language features with the intent of eliminating programmer error is at best dangerous.” (1986 page 7) (2013 page 13)
Contrast this with Sir Tony Hoare who remarked: “A language is characterized not only by what it permits programmers to specify, but even more so by what it does not allow.”
Perhaps this is the reason C++ includes so much junk. It is the mark of a good language design to be minimal, but include a minimum to support programmers at a high level. Is it Stroustrup’s excuse for C++ not removing the flaws and traps of C, rather multiplying them and introducing new traps in C++?
A good deal of thought must also be given to how features combine and how they can result in traps for programmers. Programmers must then spend an inordinate amount of time learning these traps and even then still fall into a same old trap. This is passing the burden onto all programmers, rather than a single person or small number of people responsible for the design who should have given serious thought to removing such traps. It lets the language and language designers off the hook. But programmers are very much on the hook when there are defects in their software or the software becomes difficult and extensive to maintain and modify, let alone get working in the first place.
Stroustrup thus absolves himself of this very important aspect of language design, justifying adding more that ultimately burdens programmers and lays traps for them to fall into. Helping reduce programmer error is a very important aspect of programming languages. But C++ just magnifies the traps of C.
Reducing error as far as possible is an important feature of modern denotational and axiomatic programming. John McCarthy noted in 1963:
“Proof checking by computer may be as important as proof generation. It is part of the definition of formal system that proofs be machine checkable. In my forthcoming paper, I explore the possibilities and applications of machine checked proofs. Because a machine can be asked to do much more work in checking a proof than can a human, proofs can be made much easier to write in such systems. In particular, proofs can contain a request for the machine to explore a tree of possibilities for a conventional proof. The potential applications for computer-checked proofs are very large. For example, instead of trying out computer programs on test cases until they are debugged, one should prove they have the desired properties.” — John McCarthy.
Programming languages can be defined and compilers developed to very quickly check many aspects of a program that would take a human programmer a very long time to manually check. Proof checking, reducing the potential for programmer error is a crucial part of modern programming. It has far too long been dismissed in the C world as ‘training wheels for beginners’ or ‘against programmer freedom’. It is these trite platitudes in the C world that are not “at best dangerous” they are very dangerous thinking, especially when we are talking about systems that should be correct, robust, safe, and secure. The C world lacks these assurances, and Stroustrup has summed it up in that single sentence.
“For example, seriously restricting the concept of a pointer simply forces the programmer to use a vector plus integer arithmetic to implement structures, pointers, etc.” (1986 page 7) (2013 removed)
Well that is a nonsense. While access to fields in structures might be vector + offset underneath programmers should not think that way. C pointers which came from CPL and BCPL are much too unrestricted, which is a catastrophe for correctness, safety, and security.
“Good design and the absence of errors cannot be guaranteed by mere language features.” (1986 page 7) (2013 page 13)
While true, that is no excuse for not making the language as rigorous and robust as possible. Languages should support finding errors as easily and early as possible. Languages can be a great help in developing correct software for many reasons. That is the whole reason programming languages were developed in the first place.
“The type system should be especially helpful for nontrivial tasks.” (1986 page 7)
This is at odds with the “at best dangerous” comment. Type systems are exactly about programmers being able to describe the logical types “with the intent of eliminating programmer error”, at least a particular kind of error. Clearly there is a good deal of confusion here.
