Live data from Hacker News

How do we tell truths that might hurt? (1975)

cs.utexas.edu

31–40 of 74 posts

Re: How do we tell truths that might hurt? (1975)

#31

Earlier quoted context omitted.

Dijkstra provides glimpses of his reasoning scattered across his missives. For example, for FORTRAN in https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340... " The second major development on the software scene that I would like to mention is the birth of FORTRAN. At that time this was a project of great temerity and the people responsible for it deserve our great admiration. It would be absolutely unfair to…

I don't think any language that could ever be invented could be described as leaving programming students "mentally mutilated beyond hope of regeneration", no matter how bad it is. So either he was being hyperbolic (and the sarcasm was lost on me), or he was being shockingly dogmatic. It's the kind of ranting you do with your colleagues in a pub after-hours, not something you publish in a professional context and fra…

Tenured professors, particularly of EWD's stature, get a lot of license to say what they want. I can certainly a few of my instructors who were rather colorful in a variety of ways.

Re: How do we tell truths that might hurt? (1975)

#32
post #15

Earlier quoted context omitted.

He calls out BASIC specifically because it was ubiquitous and often the only option on the machines novices would have available at the time. It logically follows that most programmers of that era, capable or otherwise, started on BASIC. Since he’s not here to tell us, I can only assume Dijkstra met the occasional exceptional individual who began learning to program in a more mathematically rigorous language during t…

> " He calls out BASIC specifically because it was ubiquitous and often the only option on the machines novices would have available at the time. " EWD's quote is from 1975 which is just barely the start of the microcomputer era (the Altair 8800 came out in '75 and the Apple II in '77), so he's not referring to those. Most people writing programs would have had access to mainframes and therefore had access to multipl…

https://en.wikipedia.org/wiki/BASIC#Explosive_growth:_the_ho...

Re: How do we tell truths that might hurt? (1975)

#34

Earlier quoted context omitted.

I don't think any language that could ever be invented could be described as leaving programming students "mentally mutilated beyond hope of regeneration", no matter how bad it is. So either he was being hyperbolic (and the sarcasm was lost on me), or he was being shockingly dogmatic. It's the kind of ranting you do with your colleagues in a pub after-hours, not something you publish in a professional context and fra…

Tenured professors, particularly of EWD's stature, get a lot of license to say what they want. I can certainly a few of my instructors who were rather colorful in a variety of ways.

I've no doubt they have license to do so without damaging their careers. That doesn't make it a good take.

Re: How do we tell truths that might hurt? (1975)

#35

Earlier quoted context omitted.

I don't think any language that could ever be invented could be described as leaving programming students "mentally mutilated beyond hope of regeneration", no matter how bad it is. So either he was being hyperbolic (and the sarcasm was lost on me), or he was being shockingly dogmatic. It's the kind of ranting you do with your colleagues in a pub after-hours, not something you publish in a professional context and fra…

If you're used to exclusively programming with line numbers and you're a kid, sure, it might take a little bit of time and instruction to comprehend that line numbers aren't necessary. But from what he wrote it just sounds like this guy is whining about (when faced with students like this) having to actually do his job.

Fortran and BASIC at the time were, in many ways, the antithesis to his ideas of what a programming language should be.

They did not permit recursion (direct or indirect). Almost by design they encouraged spaghetti code (the thing Structured Programming was meant to work against). They encouraged (or required) global state. They discouraged modularity. They were effective languages (in the sense that people got stuff done in them), but they were poor languages when compared to the capabilities of their contemporaries.

Re: How do we tell truths that might hurt? (1975)

#36

Personally, I've always thought this letter was the plainest proof that Dijkstra's pithy quotes (and those that parrot them) should not be taken seriously, no matter how entertaining they are. That list covers most the major languages of the day; what he would have to say about $(YOUR_FAVORITE_LANGUAGE) would surely be equally unkind were he alive today. That isn't to say that he did not have valid reasoning for his…

Everything Dijkstra says makes sense if you believe that computing cannot scale without correctness. He was wrong about that one thing, and to be fair to him, it's still a little amazing in retrospect, even when we can look back over the decades of history through which we've created a society dependent on vast, unimaginably complex, world-spanning computing systems built out of pieces that are virtually all broken.

And it's not like he was a lone crank railing against the 99% who were moving forward with a well-founded idea of how computing could scale indefinitely by composing incorrect programs. Just like today, 99% of programming, including programming for government programs and vital infrastructure, was done by people who were only hoping to make their own projects succeed well enough for the next six months to three years. I'm sure there were brilliant people who made intelligent arguments against the need for correctness, but their arguments didn't carry the day. Complacency and short-term thinking did.

In that context, Dijkstra's pessimism and his use of harsh, attention-getting language makes a lot of sense. How many people at the time really understood that in 2020 every part of our civilization would depend on code compiled by compilers with bugs, linked with libraries with bugs, in virtual machines with bugs, on operating systems with bugs, on CPUs with bugs in their microcode, and yet it would still all mostly work?

Re: How do we tell truths that might hurt? (1975)

#37

Earlier quoted context omitted.

Tenured professors, particularly of EWD's stature, get a lot of license to say what they want. I can certainly a few of my instructors who were rather colorful in a variety of ways.

I've no doubt they have license to do so without damaging their careers. That doesn't make it a good take.

Because it makes you uncomfortable? Or because you have reason to believe otherwise?

Re: How do we tell truths that might hurt? (1975)

#38
post #5

Some of these have aged so perfectly that I only need substitute a few letters: > Python —"the infantile disorder"—, by now nearly 30 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use. > It is practically impossible to teach good programming to students that have had a prior exposure to JS: as potential programmers t…

What a great comment. I'm sure it'll get flagged into oblivion, though - thus directly proving Dijkstra's point.

Re: How do we tell truths that might hurt? (1975)

#39
post #8
post #6

Earlier quoted context omitted.

What modern language would Dijkstra approve of?

There are so many languages available today that I'm sure there are plenty he would have approved of. For example, I think he might have appreciated Zig. If you read his work it's pretty easy to see his top priority is managing complexity and limiting surprise.

> his top priority is managing complexity and limiting surprise

Zig doesn't do either of those things. There are a fair amount of criticisms of the mental model of the author that I've seen voiced - some including security.

What's worse, the community surrounding Zig (in particular, the Discord community) operates more like a cult - any negative questioning gets you shunned.

I was personally a huge fan of Zig until a number of questionable design decisions and dismissed bug reports lead me to believe it will forever remain a toy language. I can't imagine Dijkstra approving.

Re: How do we tell truths that might hurt? (1975)

#40

Personally, I've always thought this letter was the plainest proof that Dijkstra's pithy quotes (and those that parrot them) should not be taken seriously, no matter how entertaining they are. That list covers most the major languages of the day; what he would have to say about $(YOUR_FAVORITE_LANGUAGE) would surely be equally unkind were he alive today. That isn't to say that he did not have valid reasoning for his…

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 a…

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.

Post reply on HN