Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wish the author had provided a link to the full reviews - I suspect they were more substantial.

As a aside : let's thank the FSM that Dijkstra never had access to social media - I suspect he had the kind of "abrasive" personality that would have made him probe to wasting his time and intellect arguing with all the randos of the world.




"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." — Alan Kay

Just a quote from a review of the GREEN proposal:

> They first explain the introduction of new types with "type weight = integer; type length = integer" which "define the new types "weight" and "length" as different types, both distinct from the predefined type "integer" although they have the properties of "integer"." That is a very obscure sentence: if the new types have all the properties of the old type, how can they differ?

Why, in the same way that two equal (sorry, congruent) triangles are still two different triangles. Hopefully this is not a novel concept for someone with background in maths and theoretical physics?

And this attitude of his where you can't quite pinpoint if he honestly couldn't understand something actually quite plain and simple, or just pretended not to and nitpicks, runs through almost all of his writing. The effect is that he either comes off as dim while pretentious, or just as an asshole.

And his remarks vis. statement terminators vs. separators, oh god. First of all, we sort of do have explicit statement initiators: the "function/block body begins here" token plus separators/terminators are exactly this, if you look at them from the right angle. Second, separators are just annoying for mechanistic code changes: if you switch two statements' places, but one of the was the last one in the block, you will need to also shuffle that pesky semicolon; and code generation also harder since you need to explicitly bother to not emit the separator after the last statement. And if Dijkstra has no problem with that, well, most other programmers are not him, and they do have problem with that. Not that he ever had much respect for tastes and opinions that differed from his own.


Re: weight/length, he did not think you might want to define a range?


> if you switch two statements' places, but one of the was the last one in the block, you will need to also shuffle that pesky semicolon...

  Blarg, zarg, arg.
->

  Arg, blarg. zarg,
All I want to do is switch two words places. But the pesky cap, commas and period have to be rearranged? How pretentious!

> ...you will need to also shuffle that pesky semicolon; and code generation also harder since you need to explicitly bother to not emit the separator after the last statement

A search for "Dijkstra on statement separators" returned a paper on programming languages and execution determinacy for mapping of concurrent and sequential programs

https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD472...

Based on this research, it's clear that Dijkstra was not troubled by the pesky syntax of statement delimiters during code translation as he was whether you would get the same program function after translation.

The papers conclusion spells this out:

//Having worked mainly with hardly self-checking hardware, with which non-reproducing behaviour of user programs is a very strong indication of a machine malfunctioning, I had to overcome a considerable mental resistance, before I found myself willing to consider non-deterministic programs seriously. It is, however, fair to say that I could never have discovered the calculus before having taken that hurdle: the simplicity and elegance of the above would have been destroyed by requiring the derivation of deterministic programs only. Whether non-determinacy is eventually removed mechanically —in order not too mislead the maintenance engineer— or (perhaps only partly) by the programmer himself because, at second thought, he does care —e.g. for reasons of efficiency— which alternative is chosen, is something I leave entirely to the circumstances. In any case we can appreciate the non-deterministic program as a helpful steppingstone.//

Regarding Alan Kay's quote:

His quip about nano-Dijkstras can be read as much as a statement of respect as derision.

For example, Kay's presentations occasionally repeat a rant about the hazard of semaphores for handling concurrency due to problem of deadlock. Dijkstra is known for his pioneering research on semaphores as synchronization primitives. Kay's point is well taken in a very limited context of struggles with early concurrent programming. But in the 21st century, Kay's complaint is like the Wirth's historical complaint about goto. It's true, but who thinks like that anymore?

And there's a widely held precept the abstraction is key to understanding and overcoming these complaints: you should not try to persevere writing grand plans using very low-level abstraction when you can otherwise build higher level, more appropriate abstractions from such primitives. Just as branch instructions comprise arbitrarily higher orders program logic, so do semaphores comprise higher order constructs for synchronization.

Everything about Alan Kay shows he very well understands abstraction, and he studied to be a mathematician, so Dijkstra's formalism is familiar to him. Well, a great jazz riff always has some off-notes.

So prefer to read the Kay quote as pithy, not derisory.


Semaphores are woefully too low-level mechanisms of synchronization; you have to be Dijkstra to always use them correctly. Most programmers aren't; Dijkstra's solution to that was "poor mathematicians should stay pure mathematicians", and he lamented that "the computer science current goal seems to be 'how to help programmers write programs even if they can't actually program'" (paraphrased). Well, guess what: he was wrong. Empirically.

And I know the quote's context, thank you. You may too if you want to: https://news.ycombinator.com/item?id=11799963 . So I guess I'll follow his lead: Dijkstra may have very good ideas about some technical particulars but his opinions on how programming as a discipline should be approached was simply wrong, and we can and should ignore them.


And you don't think he would adjust like Linus for example?


maybe. But that would be so sad! (as it is with Linus)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: