The paper was originally published in the CACM in 1981. This writeup is a transcription of highlights from the paper and my thoughts on them.
“I have regarded it as the highest goal of programming language design to enable good ideas to be elegantly expressed."
The languages I enjoy programming in are those that enable me to express my ideas clearly. I suppose from the standpoint of just the language, this makes sense; I know some shortcuts are taken due to implementation concerns - sometimes this makes a language feel hobbled, and sometimes it doesn't really get in the way.
There's also times where I don't always want to express the same level of detail; writing C can be tedious, but even this last week I had something come up where it was easier to just write ~50 lines of C than the equivalent Python or Go. As I start to learn Erlang and Rust, they start to feel like they fit better.
He lays out four basical principles of language design principles that he considers "to be as valid today as they were then..."
- "It was logically impossible for any source language program to cause the computer to run wild, either at compile or run time..."
- "In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
If there was any social goodness or competency requirement for software engineering, we'd all have been out of jobs a long time ago.
- "brevity of the object code produced by the compiler and compactness of runtime working data... giving programmers extra capacity to increase the quality of the program, its simplicity, its ruggedness, and its reliability."
- "the entry and exit conventions for procedures and functions should be as compact and efficient as for tightly coded machine-code subroutines".
This is another thing I guess I've always taken for granted.
- "single pass compiler... I still recommend single-pass top-down recursive descent both as an implementation method and as a design principle"
I thought his reasoning was informative: "we want our things to be read by people and people prefer to read things once in a single pass."
Design programming notations so as to minmise the number of errors that can be made.
I think this is a good goal to strive for; I think it complements writing fault-tolerant software nicely.
Later on, Hoare talks about an operating system and computer project he was on failed to complete its objectives. When he saw what IBM wanted to do with their IBM/360 project, he thought
Clearly IBM and MIT must be possessed of some secret of successful software design and implementation whose nature I could not even begin to guess at. It was only later that they realized they could not either.
While figuring out what went wrong and why his team failed to meet its goals, he had the encounter with one of the company's general managers:
You let your programmers do things which you yourself do not understand.
I've never been a tech manager, but I can see the utility of this; understanding what poeple are doing is different from knowing how to do it, and it helps to manage the complexity.
...the design of a program and the design of its specification must be undertaken in parallel by the same person, and they must interact with each other. A lack of clarity in specification is one of the surest signs of a deficiency in the program it describes,
Not knowing exactly what it is you're doing is a great way to end up with a big ball of mud. It's also helpful to think about whether what you're building is what you should be building.
Our main failure was overambition.
This is a common theme; I see this in our sprints, where we try to do too much because we don't adequately plan for it. Sometimes ambition is taking on too big of a chunk of work, and sometimes it's taking on too many parallel threads of execution.
We can think up of such good arguments for convincing ourselves and each other of the utterly absurd.
In which Sir Hoare predicts Silly Valley... all seriousness aside, this is a good reason for having people from multiple backgrounds and sanity checking outside of your org - when we have a comfortable circle of people, it's easy to convince ourselves of things that later were obviously wrong.
He also delivers his famous quote on programming:
I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.
The fact that our industry has a preponderence for the latter is probably a symptom of the aforementioned overambition and ability to convince ourselves of the absurd. Simplicity, simplicity, simplicity.
Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways.
This probably doesn't help that point either. Finally,
...I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way - and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
Reliability is generally frowned upon in the companies I've been at. Sure, we'll pay lip service to it - no one will come out and say they'd like to build unreliable systems. What happens instead is that a first pass at a system is built; sometimes this is even mostly stable. Then there is a frenzy of "SHIP! SHIP! SHIP!" without any regard to getting the software system up to a good place. We just need more features! Of course, the customers are okay with this - we've just internalised the message that software sucks, so most people are okay. This despite the fact that we'd lost big contracts due to our instability. Never matter the people burned out by constantly having to put out fires. Never mind that the features we're building could stand to have more thought put into them, extra time that would be got by doing more maintenance work.