The Mastermind of C++, or… Part 1

Ianjoyner
3 min readJul 23, 2024

--

This is the first of a series of articles examining a 2009 interview with Bjarne Stroustrup.

Thoughts that can be seen as more retrospective on the past from ‘Masterminds of Programming: Conversations with the Creators of Major Programming Languages’ (2009) (https://books.google.com.au/books?id=yB1WwURwBUQC&pg=PA14&redir_esc=y#v=onepage&q&f=false).

This series comments on the topics raised there.

Part 2 Pointers

Part 3 Abstraction

Part 4 Debugging

Part 5 Security

Part 6 C++ and OO

Part 7 C++ 2.0

Part 8 Lessons from Early C++

Part 9 Teaching

Stroustrup: “I didn’t particularly want to design a new programming language.”

That is rather like C. C was developed as an expedience to not write Unix in pure assembler, and as a means of being cross-platform. It was not a brilliant design, and any solid foundations really came from ALGOL via BCPL. C was no great language design with its many traps and flaws. C++ was also no great language design. It was always a somewhat haphazard development. Stroustrup claims he is a systems guy, not a language designer.

This is a general problem in computing when those with little expertise in a subject think they can develop software for that topic. Programmers think they can design user interfaces, but that is a specialised topic in itself. Too many programming languages have been developed by those with little experience in language design. Certainly being a ‘language designer’ is one way to get rock star status in programming. But this has left thousands and millions of programmers with having to deal with the issues in those languages.

Design of new operating systems should start with the design of a new system language from the ground up for the requirements of today’s systems (security) and programming methods. Parts of existing systems could be redeveloped. Rust seems to be a new language, but really it is still C based and while addressing security aspects that C++ is weak on, is not really a modern system development language.

C was a step backwards from ALGOL. But what of a language that was a step forwards. From Design and Evolution of C++, Stroustrup says “Pascal was considered a toy language [Kernighan 1981]”. Now Pascal, being a step forward certainly had some flaws as it explored new techniques like type checking, but as Kernighan admitted he was criticising the standard form. Useful languages, still called Pascal, came out of that like Apple’s Object Pascal (developed by Niklaus Wirth and Larry Tesler) and Unisys Slice Pascal for writing their compiler system. I have worked in both. The Unisys C Slice compiler was also written in Pascal. Compared to Pascal, for its faults, C was a step back to primitive coding.

However, this attitude that “Pascal was a toy language” seemed to permeate Bell Labs, and this leaked out to most C programmers. But it was not just against Pascal, but anything that not only looked remotely like Pascal, but anything that was not C. Designers of new languages became too afraid to step too far from C’s broken syntax. The cult that C and C++ were the only true languages spread widely in the industry. The industry must rid itself of this antipathy to anything else.

The ‘air of superiority’ of Bell towards their own creation meant that Stroustrup ignored other languages. He could have fixed Simula and extended that. He could have adapted Pascal for its cleaner syntax and true high-level concepts, interfacing to C for low-level system work. But no, he chose to magnify the flaws and traps of C. Now Stroustrup recognises there must be a better language trying to get out of C++. He could have adopted that direction back in 1979.

Stroustrup: “I’m convinced that you could design a language about a tenth of the size of C++ (whichever way you measure size) providing roughly what C++ does. However, there has to be more to a new language than just doing what an existing language can, but slightly better and slightly more elegantly.”

That is a strange comment, because all languages basically do the same thing. There is nothing magic in any language that other languages can’t do. But it is the elegance of expression of semantics and support for the process of programming from thinking to writing that is important. What also comes from Stroustrup’s statement is that indeed as I said above a new system language should be designed from the ground up with modern system and development requirements in mind.

Part 2

--

--