[madhadron]

The context of this EWD is somewhat lost to history, because Dijkstra's point of view in many cases won so thoroughly that we cannot conceive of what he was describing.

The BASIC he is describing had no call stack, nothing that would resemble a function in today's languages. FORTRAN at the time handed masses of state around in global variables and the latest version had just added subroutines and functions. This is after ALGOL 60 had established the model that we all take for granted today.

I think the bulk of practitioners today would absolutely agree with him.

[sevensor]

Back in grad school, I had the pleasure of working with some very old FORTRAN. Written conservatively using a few bits of FORTRAN 77, but mainly in a FORTRAN 66 style. The control structures I found in there would make you go crosseyed. At one point, there was a jump that took you from outside a loop to the middle of the body of the loop. Today's no-longer-all-caps Fortran manages to elude EWD's criticism by not being that language any longer. You have to use a lot of obscure compiler flags even to make the old stuff compile.

[ThrowawayR2]

Having written code in the early microcomputer BASICs, I'm reasonably familiar with the context but I think it's a bit overblown. Sure, BASIC was limited in the syntactic sugar that was available to manage program complexity but, then again, the microcomputers of the era were so limited that complexity wasn't really possible without dropping to machine language anyway. And machine language definitely didn't have any of the syntactic sugar of ALGOL 60 or other high-level languagess.

[qsort]

As a massive fan of Dijkstra myself, true but up to a point.

About programming languages I don't think there's any question he was right. Sometimes we agree with him even without realizing it, for example, the original argument of GOTO considered harmful was that GOTO statements decreased "linearity" by having the control flow jump to random places. The recent trend in mainstream PLs to adopt functional-style control structures (JS array methods, Java streams, etc.) is predicated on the exact same rationale.

I'm also in broad agreement on his stance about natural language being just flat out wrong in the context of computing.

But the man made an exorbitant amount of claims, many of which are just provably wrong. The bits about BASIC and COBOL are particularly egregious examples of his at times cavalier attitude. After all, arrogance is measured in nano-Dijkstras.

[andi999]

The goto thing is one of my pet peeve, somehow it caught on, maybe it made people feel good so they can look down on others. There is basically 2 arguments against it: Knuths article arguing for goto (read it if you havent), and the observation that gotos and state machines (which are considered best practices) are basically equivalent (just convert the goto labels to your states).

[qsort]

I'm familiar with Knuth's argument. That argument was primarily based on the fact that it's hard to replicate the exact control flow of a goto statement with structured programming. While the argument certainly has merit (a relatively more recent example is Duff's device), 2020 compilers are more often than not able to find the most optimal structure anyway, making it largely redundant. It's like saying programs should be allowed to rewrite their machine code just because in a Von Neumann architecture you are technically allowed to, there is a point but it's not in contradiction with goto statements being mostly the inferior way to solve the problem. From a 2020 perspective I'd argue that if you really need that kind of performance you are probably already inlining assembly, so it's kind of a moot point.

> gotos and state machines (which are considered best practices) are basically equivalent

WTF? State machines can be implemented in a lot of ways: mutually recursive calls, pattern matching, function pointers... In what sense are they "equivalent" to gotos? Also what does it mean that state machines "are considered best practices"?