Build Your Own Types: What Bjarne Stroustrup Learned from Simula, Fortran and Lisp

Asked which language he first fell in love with, Stroustrup says it was an Algol 60 implementation. Fortran and Pascal did not win him over, and Pascal in particular kept getting in his way. He found something simpler and more fun in low-level work, including microcode, and says that work was profitable enough to pay for his master's degree.

Then he discovered Simula, which he calls absolutely great. It was built on Algol 60 and designed mainly for simulation, but its creators effectively invented object-oriented programming, including inheritance and runtime polymorphism, along the way. Simula taught him that the difficulty of a program need not grow with the square of its size, because code can be modularized very nicely.

He contrasts the two type systems. Pascal was the simplest language Niklaus Wirth could define for his own needs, with a "highly moral tone": if you can say it in Pascal it is good, and if you cannot, it is not so good. Simula instead let you build your own types and the relations among them, which Stroustrup compares to building a domain-specific language suited to an application.

He notes that every language using the word class for a type descends from Simula, directly or indirectly. Simula's creators were mathematicians who thought in terms of sets and classes of elements rather than types. In C++, as in Simula, a class is simply a user-defined type.

Asked for a brief history of programming languages, Stroustrup names the first Fortran as the most important early step. Before it, all code was written for a specific machine in that machine's own assembly language or an extension of it. A team at IBM built a language in which people could write what they really wanted, and it was aimed at engineers and physicists, hence "formula translation".

Portability came as a side effect. Programmers could now write in the terms humans used, and a program translated that into what the machine needed. Stroustrup draws a lesson he still holds to: raise the language to the human level, but do not lose efficiency. He adds that business people, a different kind of human, ended up with COBOL.

Early Fortran lacked a precise notion of type, a precise notion of scope, and the translation phases we take for granted today, such as lexical syntax and semantics. Stroustrup refuses to fault it, since it was the biggest breakthrough in the history of programming. Algol followed and was very pretty, but most people in commerce and science considered it useless because it was not flexible or efficient enough.

Simula came along to make that idea more flexible by letting you define your own types, and that is where he became very interested. Kristen Nygaard, the main idea man behind Simula, was a visiting professor at his university in the late 1960s. Stroustrup says he learned object-oriented programming largely by listening to him, because once Nygaard got going it was hard to get a word in.

The host calls object-oriented programming a leap of abstraction, and Stroustrup agrees it was not obvious at the time. Many people tried something similar, and few came up with anything as wonderful as Simula. He says some people built careers and earned PhDs by forgetting or never knowing about it.

For him the key idea was getting his own types, and that idea runs through the lineage of C++: better, more flexible and more efficient types. You write a program with types appropriate to your problem and to the constraints of your hardware and software environment. Most people picked up on virtual functions and inheritance, which he calls an interesting and still major part, but not the most fundamental.

He illustrates why relating types matters with a city simulation of vehicles. Without inheritance you would write big case statements that treat bicycles, cars and fire engines separately when turning left. Instead, you tell the base class to turn left and each kind of vehicle does it in its own way.

Stroustrup says this was a real example: Simula was used to simulate and optimize emergency services somewhere in Norway in the 1960s. It shows why inheritance and runtime polymorphism were needed, since you cannot rewrite your code every time a new kind of vehicle comes along.

The host points out that Stroustrup skipped John McCarthy and Lisp. Stroustrup says he is telling the part of the history that shaped him, and that Lisp is obviously important and interesting. He notes that lots of people write code in it and then rewrite it in C or C++ when they move to production.

His world is constrained by performance, reliability, deployability and the cost of hardware, and he does not like things to be too dynamic. It is hard to write code that is perfectly flexible and can also be deployed on a small computer or inside a telephone switch. If something fails on a switch late on a Sunday night, the chance that a programmer is around to use a debugger is zero.

He accepts that perhaps 70 to 80 percent of all code is not under these constraints, but says someone has to do the job he does, bridging flexible high-level languages and the hardware. The software that lasts 10, 20 or 30 years is robust and operates under very constrained conditions. He calls C++ one of his favorite languages and says Lisp is too, for different reasons.

He distinguishes Lisp from functional languages such as ML and Haskell, which have a different kind of beauty. Stroustrup says he tries to learn from every language he meets, asking what would make work on his kind of problems, under his kind of constraints, better. We can surely do better than we do today, he says.

Stroustrup says he can admire Lisp and C++ together because he understands why Lisp is popular and can see the beauty of its ideas. It is simply less relevant to the world he works in, where the code must run on constrained hardware and survive for decades.

His closing point is a habit of mind rather than a loyalty to a tool: study the languages you meet, including ML and Haskell, and ask what would let you do your own work better. That stance fits his broader story, in which a lesson from Simula, Fortran or Algol keeps feeding back into the design of C++.