undefined | Better HN

0 pointsqsort5y ago0 comments

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.

0 comments

andi9995y ago

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).

qsortOP5y ago

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"?

j / k navigate · click thread line to collapse