[peterkelly]

The most important one in the context of 2025 is this one:

On the foolishness of "natural language programming". https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

[dilawar]

Thanks for the link. Great read.

Apparently Dijesktra loved using em-dash!

[beezlewax]

If you look at the scanned pdf from what looks like a typewriter written document, he was using two hyphens everywhere. Links on the top of the page.

[sfn42]

I love that essay. It's such a joy to read, and even though it is very short and to the point it says so much both about the topic itself and society at large.

And its just so obviously correct.

[bazoom42]

It is not obviously correct. The unstated premise is that programming is - or should be - similar to writing mathematical proofs.

[Atlas667]

[flagged]

[cubefox]

Setting aside the the elephant in the room (modern coding LLMs are in some sense indeed compilers for natural language -- except they still "compile to" ordinary programming languages) it nonetheless seems to me that even conventional programming languages use too little, not too much, natural language.

Example:

- "&&" rather than "and",

- "||" rather than "or",

- "if (A) B" rather than "if A then B"

This only makes the code harder to read for beginners without apparent benefit. I'm not sure whether Dijkstra would have agreed.

Thankfully though, programming languages already use mostly explicit (English) language in function names. Which is a much better situation than in mathematics, where almost every function or operator is described by a single nondescript letter or symbol, often even in Greek or in a weird font style.

There is a tradeoff between conciseness and readability. Mathematics has decided long ago to exclusivly focus on the former, and I'm glad this didn't happen with programming. If we read Dijkstra as arguing that only focusing on readability (i.e., natural language) is a bad tradeoff, then he is right.

[pm215]

I suspect Dijkstra would have disagreed with you about "and" and "or", judging from his criticism of the technical report which had the line "even the standard symbols used for logical connectives have been avoided for the sake of clarity".

Personally I think one advantage of '&&' and '||' is that it's clear they're a notation that you need to know the syntax and semantics of. For instance typically '&&' is "short-circuiting" and will not evaluate its RHS if the LHS is true; a natural-language "if a and b then ..." doesn't suggest that critical detail or necessarily nudge you to go and check. (Not that Dijkstra was in favour of short-circuiting logical operators, to judge by https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD100... point 4...)

More generally, I'm not sure of the benefit of tailoring the language syntax for beginners rather than experienced practitioners; the advantage of '&&', '||' and the rest of the "C-like" syntax stuff in a new language is that it's familiar to a wide base of existing experienced programmers.

[SirHumphrey]

Working a bit with some old programming languages that are very natural language like (FORTRAN’s .and. and .or. or COBOL’s IS GREATER THAN) I don’t think the readability increases that much, maybe the benefit is more approachability. In a more symbolic language skimming code is much easier because the symbols provide visible distinction between more syntactic control flow and the declared functions, variables etc.

[dragonwriter]

Note that only about 1/3 of this critique (the last example, and with slightly different actual syntax in place of the preferred syntax) of "conventional programming languages" applies to the #1 language on the Tiobe index, which does, in fact, use and instead of && and or instead of || but uses ":" instead of "then" in if statements.

[renox]

For && and || I disagree: they are 'shortcircuiting' operators and as such they deserve a différent name than just 'and', 'or'. That said &| should have been named and,or which would have freed &| to use for the shortcircuit operators.

[mkoubaa]

Friend, this filter is a feature not a bug.

[f1shy]

This is gold! Thanks.

[adamddev1]

> when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.

This hits so hard. cough dynamic typing enthusiasts and vibe coders cough

[noosphr]

> Another thing we can learn from the past is the failure of characterizations like "Computing Science is really nothing but X", where for X you may substitute your favourite discipline, such as numerical analysis, electrical engineering, automata theory, queuing theory, lambda calculus, discrete mathematics or proof theory. I mention this because of the current trend to equate computing science with constructive type theory or with category theory.

https://www.cs.utexas.edu/~EWD/transcriptions/EWD12xx/EWD124...

[oivey]

I’m not sure that is the focus of most serious dynamic language. For me, it’s the polymorphism and code re-use it enables that the popular static languages generally aren’t close to catching up to.

[bazoom42]

It is just a classical Dijkstra strawman - hiding a weak argument behind painting everybody else as idiots. In fact it is much easier to make dangerous undetected mistakes in C than it is in Python.