Live data from Hacker News

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

cs.utexas.edu

51–60 of 74 posts

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

#51

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.

I didn't have an impression that line numbers were important. Most of the time they did nothing and were unwieldy to maintain, they were more nuisance than anything else.

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

#52
post #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.…

Good points. I think a way of looking at it is that much of software development we do today is about communication, not engineering. Think of web-sites they are all about communicating something. And in a sense when you write a program you do so to communicate with the computer.

Of course there are critical software engineering projects as well, Boeing MAX comes to mind.

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

#53
post #50
post #40

Earlier quoted context omitted.

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…

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

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

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

#54
post #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.…

> 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,

That is clearly wrong if one is willing to take a moment to stop gazing at the wonder of pure mathematics and look at the outside world. There is no notion of "correctness" for the pyramids of Egypt, the dykes of the Netherlands, Milan Cathedral, or the world economy and yet those huge-scale systems all function.

> Dijkstra's pessimism and his use of harsh, attention-getting language makes a lot of sense.

It makes sense in terms of Dijkstra's personality, but it makes no logical sense. If you believe mathematical correctness is such a valuable principle, then you should be able to leverage that same principle in one's own arguments. The fact that Dijkstra couldn't dispassionately prove that correctness was vital and had to resort to emotionally-loaded weasel words undermines his own claim.

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

#55
post #24

Earlier quoted context omitted.

What's with the hate for python. I've noticed some hate this irl and it's strange. Python is one of the best languages out there right now in terms of ease of use and future maintainability (with types).

I love this quote: "There are only two kinds of languages: the ones people complain about and the ones nobody uses". Bjarne Stroustrup.

There's a lot to complain about for python. But I see genuine hate. People, groups and companies who literally refuse to use it.

I had an interviewer tell me that I couldn't code up the solution in python. I think it might be because python is so easy that people look down on it.

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

#56
post #9

Earlier quoted context omitted.

I disagree and I believe most developers would agree that it would have been a far better use of time to learn 6502 assembly than Apple BASIC, at least if one's goal was to actually learn how to program computers. To this day if I saw 6502 assembly on a resume I'd be intrigued and if I saw BASIC I'd view it as a yellow flag.

Then you say "There are better options than BASIC for teaching new programmers." That's not what was written. I've read countless anecdotes from perfectly capable programmers who not only learned, but first discovered their interest in the field, via BASIC. No language "mentally mutilates programmers beyond hope of regeneration". And BASIC probably isn't even the worst one for learning purposes.

People had to create specialized languages for learning purpose to compete with builtin graphics feature of basic.

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

#57
post #36

Earlier quoted context omitted.

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

> 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, That is clearly wrong if one is willing to take a moment to stop gazing at the wonder of pure mathematics and look at the outside world. There is no notion of "correctness" for the pyramids of Egypt, the dykes of the Netherlands, Milan Cathedral, or the…

Imo, the real issue is that people seem to think that smart mathematicians or scientists don't argue like normal people, don't get emotional when arguing and always talk from divine truth.

The issue have nothing to do with mathematical correctness, so you can't apply the same principles. This is not math. But, Dijkstra's it's not being logical in arguments, because he is not of dick and likely this style of arguing was working for him in his life.

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

#58
post #36

Earlier quoted context omitted.

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

> 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, That is clearly wrong if one is willing to take a moment to stop gazing at the wonder of pure mathematics and look at the outside world. There is no notion of "correctness" for the pyramids of Egypt, the dykes of the Netherlands, Milan Cathedral, or the…

> There is no notion of "correctness" for the pyramids of Egypt, the dykes of the Netherlands, Milan Cathedral, or the world economy and yet those huge-scale systems all function.

I think it's impossible to come up with a rational judgment of whether the world economy "functions." I mean, those of us who are alive are alive, but there are a lot of things that have happened that haven't been ideal.

Besides the world economy, nothing you mention has the functional complexity of a large piece of software, and none of it was designed and built with much confidence, other than confidence that came from similarity to previous designs, and from an optimistic outlook that issues encountered during construction could be coped with. This wall is cracking, so we tear it down and rebuild it a little thicker. We have a few centuries, after all. I think you're right that modern software projects are analogous to ancient pyramids and medieval cathedrals. That's pretty much where we are. Yet somehow, working at that low level of sophistication, we've built working software that is orders of magnitude more complex than cathedrals.

I'm not saying I know how to improve on the situation, or even that we can; I'm just pointing out how different it is from, say, contemporary structural engineering where we can analyze the design of a novel structure and have a pretty good idea of whether it will be safe based on its geometry and known characteristics of materials and how they're joined. It's amazing that we've reached the scale we have with nothing comparable.

> If you believe mathematical correctness is such a valuable principle, then you should be able to leverage that same principle in one's own arguments.

The idea that mathematical reasoning is on some spectrum with dispassionate discourse has motivated hundreds of years of attempts to improve natural language by making it more mathematical. Result: some interesting contributions to philosophy but very little change in how people communicate. People are still people.

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

#59
post #27

Earlier quoted context omitted.

If I understand correctly, ALGOL had better ways of structuring code into functions than FORTRAN did. This let ALGOL do what eventually was called "structured programming", and FORTRAN do what was called "plate of spaghetti" programming. This is not the same as saying that EWD thought that ALGOL was good ...

I imagine he had at least some fondness for Algol 60 since he is co-credited with writing the first compiler for it.

That might give you fondness. Or disgust. In his case, I have no data about which one won.

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

#60
post #20

Earlier quoted context omitted.

I suspect, none of them. If he did approve of one, it would probably be Haskell. And, for all his complaining, I don't know of any language that he authored. He's sure good at telling everyone that they're doing it wrong, though...

Dijkstra co-created a rather influential language called Algol 60[1]. It and its immediate descendants are still used in scholarly CS work because it's so good for clearly describing algorithms. Past that, the influence of Algol 60 on virtually all modern programming languages is hard to overstate. [1] https://en.wikipedia.org/wiki/ALGOL_60

Well, he co-authored a compiler. From what your link says, he wasn't part of the committee that created the language.
Post reply on HN