This is the ninth and last of a series of articles examining a 2009 interview with Bjarne Stroustrup. The first part is here with links to the other parts:
Teaching
Stroustrup took up a teaching position in academia at Texas A&M University.
Question: “What did you learn about teaching programming to beginners?”
He wrote a book ‘Programming: Principles and Practice Using C++’
C++ breaks so many principles: ‘Separation of Concerns’, ‘Complexity conquered by simplicity’, as foundational ones.
Stroustrup: “A beginner’s book must serve several purposes. Most fundamentally, it must provide a good foundation for further learning and also provide some practical skills.
C++ should not be used to teach beginners (neither should C). Programmers should get sure foundations before learning any systems language. Remember from above, Stroustrup is a systems guy, not a general programmer.
Grappling with the flaws and traps of C and C++ are not a good foundation, in fact distracts from foundations. New programmers think learning the traps and flaws of a language must be a major part of learning programming — it should not be.
Pascal was disdained by C people because they saw it ONLY as a teaching language. They only read Wirth’s first aim: “The development of the language Pascal is based on two principle aims. The first is to make available a language suitable to teach programming as a systematic discipline based on certain fundamental concepts clearly and naturally reflected by the language. The second is to develop implementations of this language which are both reliable and efficient on presently available computers.” From the Introduction of the Report part of Wirth and Jensen, but only written by Wirth.
The second was ignored. A language being good for teaching does not mean it is impractical for real-world work. That seems to be the assumption of the C world. Unfortunately, Pascal had a few faults due to its being an early attempt at typing systems. This gave both Pascal and type systems a bad name, unfairly in most cases. Pascal’s syntax was not the problem, in fact Pascal syntax is rather clean and elegant. (I never liked Wirth’s style of typing keywords in uppercase.)
The problem is that other languages with similar clean syntax were tarred with the same brush as Pascal, even though they did not have the same faults. C programmers just could not get over it. They assessed everything on syntax (despite Kernighan’s paper being a much deeper assessment) and not the deeper issues. The lie of disparagement was just a convenience.
In ‘The School of Niklaus Wirth: The Art of Simplicity’ in the reproduction of Wirth’s 1985 Turing Award lecture ‘From Programming Language Design to Computer Construction’ https://dl.acm.org/doi/pdf/10.1145/2786.2789 Wirth appraises Pascal in retrospect:
“Occasionally, it has been claimed that Pascal was designed as a language for teaching. Although this is correct, its use in teaching was not the only goal. In fact, I do not believe in using tools and formalisms in teaching that are inadequate for any practical task. By today’s standards, Pascal has obvious deficiencies for programming large systems, but 15 years ago it represented a sensible compromise between what was desirable and what was effective. At ETH, we introduced Pascal in programming classes in 1972, in fact against considerable opposition. It turned out to be a success because it allowed the teacher to concentrate more heavily on structures and concepts than features and peculiarities, that is, on principles rather than techniques.”
Note Wirth’s honest and candid assessment of Pascal — something not seen in the C world. Notice that the teaching was to emphasise concepts, not just training programmers to avoid language peculiarities which is far too much the kind of programmer training demanded for C and C++. That is also the difference between teaching and training. Teaching involves being able to assess and be critical of the tools themselves. Training is more about acceptance of the foibles. And I find much of what Stroustrup says and write is about the latter.
From ‘Reflections about the Development of Pascal’: https://dl.acm.org/doi/pdf/10.1145/154766.155378
“The decisive factor, in the author’s opinion, is the simplicity, frugality, and coherence of the language. A limiting factor to this is the architecture of the underlying machine. In this respect, the question “how well is the computer suited for this kind of language?” becomes more significant than the opposite question, “how well is the language suited for the machine?” The author feels indeed strongly about this point, and recommends future hardware designers to confront themselves seriously with the first question, before yielding to the well-known policy of answering every problem with the common and omnipotent reply: “There is a bit somewhere”.”
We should develop machines that have sufficient support for higher-level programming for the efficient performance of programs, not bend our programs to machines and overly burden the programmer with performance issues. From what Stroustrup has written about programming to the machine, he is far more into answering the second question. The second question is about certain assumptions on machine architectures and exposing them to programmers. This locks programs into those processor styles and into the languages themselves. C and C++ have achieved that lock in to the detriment of the programming industry as a whole.
Hence, I think that new programmers should be taught good foundations and principles, not the compromises in certain languages, of which there are far too many in C and C++, compromises around constraints of the 1960s.
Stroustrup: “Unfortunately, far too often, teaching fails to maintain a balance between theory/principles and practicalities/techniques.”
Having followed the same path of going from industry as mainly a system programmer to over ten years of teaching, I agree with the comment. We are always trying to balance illustrating principles with practical foundations. It is a feedback loop. When a learner has done some programming they can then appreciate what is being taught in terms of principles to help avoid the problems they have found. It is a recursive process and people take steps ahead.
For example, prohibitions on goto are not really understood until a student can understand the messes that can be created with undisciplined use resulting in rats-nest programs. Sure, as Knuth pointed out, we can use goto in disciplined ways, but that results in structured programming with no need for goto. Unfortunately, many use Knuth’s paper to react against the prohibition on gotos and end up using goto in undisciplined ways.
Practicalities and techniques should not be about how to avoid the traps and flaws or dealing with the arcaneness in a language. That is a waste of time and locks a new generation of programmers into the same old treadmill.
C++ is of little help. In fact, students spend far too much effort on the obscurities of C++ and most likely miss any principles or good techniques. Like C undermines structured programming with too many goto-like escapes, C++ undermines many of the principles of object-oriented programming. So what are students to make of that?
Stroustrup: “My opinion is that both attitudes are far too extreme and lead to poorly structured, inefficient, and unmaintainable messes even when they do manage to produce minimally functioning code.”
This is why C++ is such a poor teaching vehicle — programmers must grapple with the problems of the language before they get such important lessons. C++ is the extreme towards practicalities/techniques, which I emphasise are more about avoiding traps and flaws. Programming must be more than just learning all the foibles of particular languages. The focus must be on programming, the process of programming and the disciplined organisation of programs, not on the problems of any language. A language must provide the correct abstractions in clear and meaningful form.
On his latest book at that time, Stroustrup: “Maybe I should add a label to my book: “no cute cuddly animals were abused in this book’s examples.” Perhaps not, but programming and programmer thinking have certainly been tortured.
Conclusion
Well, draw your own conclusions, from both this series and the previous series at: https://medium.com/@ianjoyner/e1ea529bcf60
I’m sure enough has been said on the subject!
