8 ms·

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/

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.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

sfn42 11mo ago
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.
- Atlas667 11mo ago
  [flagged]
  - f1shy 11mo ago
    IMHO you are going way way way to far. Far in the weeds.
    - BigGreenJorts 11mo ago
      Nah, I think they're probably seeing warning signs. So much Djikstra's writing is pseudo intellectual pretensious word salad. Which is a shame bc he was an actual intellectual.
- bazoom42 11mo ago
  It is not obviously correct. The unstated premise is that programming is - or should be - similar to writing mathematical proofs.
  - adamddev1 11mo ago
    The proofs/programs (Howard/Curry) correspondance has been fairly well established I think.
    - marcosdumay 11mo ago
      It's the requirements discovery phase that always breaks every pure mathematical treatment of software development. (And also, like DW points, that software is way more complex. But on this case, it's the requirements discovery.)
      - moi2388 11mo ago
        That’s because it’s not pure math, but applied math. Which also has the requirements discovery phase.
        marcosdumay 11mo ago
        Yes, and constructing mathematical theories is completely different from finding proofs.
    - bazoom42 11mo ago
      It is a bit like architecture is just physics or painting is just chemistry. Technically true in some reductionist sense, but not necessarily the most useful way to think about it.
  - sfn42 11mo ago
    No, the premise is that programming is the act of writing precise specifications, which is easier in a precise language. Similarly to mathematical proofs.
f1shy 11mo ago
This is gold! Thanks.
dilawar 11mo ago
Thanks for the link. Great read. Apparently Dijesktra loved using em-dash!
- beezlewax 11mo ago
  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.
adamddev1 11mo ago
> 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 11mo ago
  > 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/EWD1243a.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD12xx/EWD124...
- oivey 11mo ago
  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.
  - dpark 11mo ago
    I’m curious, can you give an example that wouldn’t be solved by polymorphism in a modern statically typed OO language? I would generally expect that for most cases the introduction of an interface solves for this. Most examples I can think of would be things like “this method M expects type X” but I can throw in type Y that happens to implement the same properties/fields/methods/whatever that M will use. And this is a really convenient thing for dynamic languages. A static language proponent would call this an obvious bug waiting to happen in production when the version of M gets updated and breaks the unspecified contract Y was trying to implement, though.
    - oivey 11mo ago
      That’s basically the main example I’d give. I think the static proponents with that opinion are a little myopic. Those sorts of relationships could generally be statically checked, it’s just that most languages don’t allow for it because it doesn’t fit in the OOP/inheritance paradigm. C++ concepts seem to already do this. The “bug waiting to happen” attitude kind of sucks, too. It’s a good thing if your code can be used in ways you don’t originally expect. This sort of mindset is the same trap that inheritance proponents fall into. If you try to guess every way your code will ever be used, you will waste a ton of time making interfaces that are never used and inevitably miss interfaces people actually want to use.
cubefox 11mo ago
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.
- SirHumphrey 11mo ago
  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.
- pm215 11mo ago
  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/EWD1009.html 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.

sfn42 11mo ago

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.

Atlas667 11mo ago
[flagged]
- f1shy 11mo ago
  IMHO you are going way way way to far. Far in the weeds.
  - BigGreenJorts 11mo ago
    Nah, I think they're probably seeing warning signs. So much Djikstra's writing is pseudo intellectual pretensious word salad. Which is a shame bc he was an actual intellectual.
bazoom42 11mo ago
It is not obviously correct. The unstated premise is that programming is - or should be - similar to writing mathematical proofs.
- adamddev1 11mo ago
  The proofs/programs (Howard/Curry) correspondance has been fairly well established I think.
  - marcosdumay 11mo ago
    It's the requirements discovery phase that always breaks every pure mathematical treatment of software development. (And also, like DW points, that software is way more complex. But on this case, it's the requirements discovery.)
    - moi2388 11mo ago
      That’s because it’s not pure math, but applied math. Which also has the requirements discovery phase.
      - marcosdumay 11mo ago
        Yes, and constructing mathematical theories is completely different from finding proofs.
  - bazoom42 11mo ago
    It is a bit like architecture is just physics or painting is just chemistry. Technically true in some reductionist sense, but not necessarily the most useful way to think about it.
- sfn42 11mo ago
  No, the premise is that programming is the act of writing precise specifications, which is easier in a precise language. Similarly to mathematical proofs.

f1shy 11mo ago

This is gold! Thanks.

dilawar 11mo ago

Thanks for the link. Great read. Apparently Dijesktra loved using em-dash!

beezlewax 11mo ago
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.

adamddev1 11mo ago

> 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 11mo ago
> 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/EWD1243a.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD12xx/EWD124...
oivey 11mo ago
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.
- dpark 11mo ago
  I’m curious, can you give an example that wouldn’t be solved by polymorphism in a modern statically typed OO language? I would generally expect that for most cases the introduction of an interface solves for this. Most examples I can think of would be things like “this method M expects type X” but I can throw in type Y that happens to implement the same properties/fields/methods/whatever that M will use. And this is a really convenient thing for dynamic languages. A static language proponent would call this an obvious bug waiting to happen in production when the version of M gets updated and breaks the unspecified contract Y was trying to implement, though.
  - oivey 11mo ago
    That’s basically the main example I’d give. I think the static proponents with that opinion are a little myopic. Those sorts of relationships could generally be statically checked, it’s just that most languages don’t allow for it because it doesn’t fit in the OOP/inheritance paradigm. C++ concepts seem to already do this. The “bug waiting to happen” attitude kind of sucks, too. It’s a good thing if your code can be used in ways you don’t originally expect. This sort of mindset is the same trap that inheritance proponents fall into. If you try to guess every way your code will ever be used, you will waste a ton of time making interfaces that are never used and inevitably miss interfaces people actually want to use.

cubefox 11mo ago

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.

SirHumphrey 11mo ago
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.
pm215 11mo ago
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/EWD1009.html 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.