> if you switch two statements' places, but one of the was the last one in the block, you will need to also shuffle that pesky semicolon... Blarg, zarg, arg.

> if you switch two statements' places, but one of the was the last one in the block, you will need to also shuffle that pesky semicolon... Blarg, zarg, arg. -> Arg, blarg. zarg, All I want to do is switch two words places. But the pesky cap, commas and period have to be rearranged? How pretentious! > ...you will need to also shuffle that pesky semicolon; and code generation also harder since you need to explicitly bother to not emit the separator after the last statement A search for "Dijkstra on statement separators" returned a paper on programming languages and execution determinacy for mapping of concurrent and sequential programs https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD472.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD472... Based on this research, it's clear that Dijkstra was not troubled by the pesky syntax of statement delimiters during code translation as he was whether you would get the same program function after translation. The papers conclusion spells this out: //Having worked mainly with hardly self-checking hardware, with which non-reproducing behaviour of user programs is a very strong indication of a machine malfunctioning, I had to overcome a considerable mental resistance, before I found myself willing to consider non-deterministic programs seriously. It is, however, fair to say that I could never have discovered the calculus before having taken that hurdle: the simplicity and elegance of the above would have been destroyed by requiring the derivation of deterministic programs only. Whether non-determinacy is eventually removed mechanically —in order not too mislead the maintenance engineer— or (perhaps only partly) by the programmer himself because, at second thought, he does care —e.g. for reasons of efficiency— which alternative is chosen, is something I leave entirely to the circumstances. In any case we can appreciate the non-deterministic program as a helpful steppingstone.// — Regarding Alan Kay's quote: His quip about nano-Dijkstras can be read as much as a statement of respect as derision. For example, Kay's presentations occasionally repeat a rant about the hazard of semaphores for handling concurrency due to problem of deadlock. Dijkstra is known for his pioneering research on semaphores as synchronization primitives. Kay's point is well taken in a very limited context of struggles with early concurrent programming. But in the 21st century, Kay's complaint is like the Wirth's historical complaint about goto. It's true, but who thinks like that anymore? And there's a widely held precept the abstraction is key to understanding and overcoming these complaints: you should not try to persevere writing grand plans using very low-level abstraction when you can otherwise build higher level, more appropriate abstractions from such primitives. Just as branch instructions comprise arbitrarily higher orders program logic, so do semaphores comprise higher order constructs for synchronization. Everything about Alan Kay shows he very well understands abstraction, and he studied to be a mathematician, so Dijkstra's formalism is familiar to him. Well, a great jazz riff always has some off-notes. So prefer to read the Kay quote as pithy, not derisory.