C.A.R. Hoare thinks program languages should primarily support design and documentation, with programming being a distant third.
Two papers by Turning Award winner C.A.R. Hoare, both on programming language design. I like to write up interesting tidbits and copy fun quotes, this isn’t a full summary
If you don’t have time to read it all, here’s the tldr: C.A.R. Hoarse invented switch statements, warned us about buffer overflows, and loves Algol 60. (Not Algol 68, which I wrote about.)
Notes on the features that Hoare considers the most important of language design.
This paper presents the view that a programming language is a tool that should assist the programmer in the most difficult aspects of his art, namely program design, documentation, and debugging.
C.A.R. Hoare invented the switch statement. He designed it as an extension for Algol 60 for an alternative to a common GOTO pattern where you would create an array of jump locations and then index into the array.
switch SS := L1, L2, L3;
go to SS[i];
LI: Q1; go to L;
L2: Q2; go to L;
case i of
Hoarse doesn’t like how high level languages (high level at the time) fail at hiding the details, such as with references. This sounds like an early warning about buffer overflows. He says that high level languages could have prevent them wholy, but the introduction of reference undid all that work.
References are like jumps, leading wildly from one part of a data structure to another. Their introduction into high-level languages has been a step backward from which we may never recover.
Finally, something I have never heard about before, but goddamn do I want to learn more about:
According to current theories of structured programming, every large-scale programming project involves the design, use, and implementation of a special-purpose programming language, with its own data concepts and primitive operations, specifically oriented to that particular project.
Someone once said about language design (and I can’t find the article to link to) that there is an order of magnitude difference in the amount of talk on comment syntax v syntax, and syntax v. semantics. It was implied that the hard work is on the semantics, while the design dilettantes focus on the less important schtick. I liked thinking about that while reading this paper by Turing recipient C.A.R. Hoare with huge segments on the different choices for comments.
A language design projects takes about ten years from initiation to “successful” standardization."
There was an ooooold blog post on the difficulties Perl 6 (now Rako) has faced in it’s development (Critique of the Perl 6 RFC Process by Mark-Jason Dominus ) and it’s very similar to the overarching problems Hoare identifies in language development from the 70s: a spec that takes a short time, by authors of unknown technical experience, and a long implementation by programmers who find all problems a bit too late.
Some things never change.
He has the required discussion on why programming is different from proper engineering, like designing a car.
The main reason why computer programming is more difficult (in this respect) than other branches of engineering is that every decision is capable of interacting in an unexpected way with every other decision.
Hoare has a nice table of different features added in languages. I’m not going to recreate the entire table, but here are the ones that stood out to me.
- Fortran – Subroutines and parameters
- Algol 60 – Nested structures, local variables, dynamic arrays, and recursion, all implemented with a run-time stack. Holy shit what a leap forward. No wonder Hoare constantly praises it.
- Lisp – Functions as programming, garbage collection (which inspired my favorite paper, Generation Scavenging: A Non-disruptive High Performance Storage Reclamation Algorithm, by David Ungar)
- APL – Weird types as primitive data types
- Pascal – User-defined types, omission of attractive features (how brave!)
This paper joins many others of its time in discussing the Department of Defense Higher Order Language (DoD HOL) project that would eventually produce Ada. It must have been simply the most important topic of the day. Edward Dijkstra said this about the recommendations, “Ada was such a mess that I shuddered at the thought that Western security would depend on it and that I would feel much safer if the Red Army were to adopt it as well.” (EWD1057)
I like his view on the goal of a programming language:
The essential purpose of a programming language is to help in building a bridge between a high-level abstract (formal or informal) specification of a program and its execution in the code of some machine.
I like his view on the differences between academics and other programmers:
Academics suffer from the same prejudices and prior commitments as other programmers; it is just that they are more articulate in expressing a justification for their views.
And again, to back up his entire point of these two papers.
The main merit of a good high-level programming language is the aid which it give to the intellect in the design and documentation of a computer program; the aid which it gives in actually coding the program may be secondary.