171–180 of 229 posts
Earlier quoted context omitted.
I really think that it is a disservice to Dijkstra to remember him as the Don Rickles of computer science.
I think of him more as the Truman Capote of computer science. Backus' characterization of one particular EWD as "bitchy" is right on the money.
Dijkstra is a wonderful source of memorable quotes and hot takes from the early days of software. A sampling: > “The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.” (Dijkstra, 1972) > “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.” (Dijkstra…
Half of his clever quotes are completely bonkers though and have been disproven by history. How many of you are proving your programs correct before entering them into the computer? Because that is the only correct way to program. And remember he disparaged Margaret Hamiltons software methodology. Sure, she helped put a man on the moon, but apparently she did it the wrong way . I suspect geeks like Dijkstra because h…
I don’t know how amenable he was to his arguments possibly being incorrect, but I love working with/knowing people who are that combination of outspoken and not-overly-stubborn. People like that are a firehose of ideas and knowledge, even if not everything they say is correct. They also usually are “passionate” about their work and at least competent enough to have unorthodox opinions that don’t just sound blatantly stupid.
Most people are too timid or low-ability to be outspoken at all.
Earlier quoted context omitted.
There’s no other way to do it for this type of a brain. I know because I have the same type of brain. I spend 90% of my time formulating descriptions of the problem and the desired end state Hallucinating futures where the state of the world is in a state that I either wanted to be or that somebody’s asking me to build Once you know your final end state, then you need to evaluate the current state of the things that…
Interesting. I try to do something like this, but way simpler and my productivity is low right now. Maybe more practice will help. Would you say you're usually good at doing this and getting results?
You use a problem solving process built on structured analysis by first defining the problem in terms of an Undesired Result (R1), Desired Result (R2) — the S and S’ in Andrew’s process. Then, you determine the Starting Point in terms of the logical structures that generate your R1; these structures can be a sequence of cause-effect, a structural decomposition (e.g. of organization, geography, etc.), a classification, or some combination of the three. From this structure you can hypothesize experiments to confirm/disconfirm where the causes are. With these causes in hand, you can generate possible solutions or corrective actions. Finally, you’d evaluate your alternatives and arrive at your solution to move from R1->R2.
MPP’s problem solving process has the additional advantage of structuring your actions/results in a way that makes writing a document or presentation simple and straightforward, to convince others for example.
Check out the book if you’re interested in improving your problem solving and analysis skills.
I was a grad student in Austin in the 1990s. If Dijkstra showed up for one of the regular department-wide "lunch and learn" type talks, there was a bit of a buzz among the grad students in the room... you knew he was going to pop off with a total left-field question and the results would be pretty entertaining. Free cookies AND comic humiliation from a giant in the field! It was standing-room-only.
Any stories that stand out/are worth sharing?
2. Asking a networking guy about the use of the term "stack" in his talk. A little unfair, given that the two uses (push/pop stack vs. network protocol stack) are unrelated, but still a bit funny.
Earlier quoted context omitted.
The whole structured programming practically birthed the industry, so it’s hard to say he has less direct impact in the industry though.
It was controversial at the time. Dijkstra advocated "single entry, single exit" for each control block. Programs should be composed of such blocks. Makes for very neat flowcharts. Good for entry and exit conditions. Single entry wasn't that controversial. Single exit, though, means no "break", or "continue" for loops, and no early returns from functions. This forces a rather convoluted style. Try writing a loop of t…
It is a different way of thinking though and it takes a while before your mind stops reaching for while loops.
Earlier quoted context omitted.
Most real world problems don’t fit into neatly into hierarchical structures. OOP pushes you towards trying to model everything in the world an objects with strictly defined operations that can be performed on, where those actions are determined by the data type itself. You end up being forced to co-mingle your data structure design, with your data processing design. Which tends to be rather unhelpful. Keeping your da…
In OOP you can have data structures and algorithms separated. You can use composition over inheritance without issues. The fact that a language is strong typed and you get compilation errors if you forgot something is a big plus. OOP is fundamentally about no static variables.
That is not at all unique to OOP, and in fact OOP makes the problem undecidable due to ad-hoc subtyping. More structured languages like ML, Haskell, and Rust are much easier to reason about and have much stronger type systems.
> "Whether written using a fountain pen or typewriter, Dijkstra’s technical reports were composed at a speed of around three words per minute. “The rest of the time,” he remarked, “is taken up by thinking.”9 For Dijkstra, writing and thinking blended into one activity. When preparing a new EWD, he always sought to produce the final version from the outset." > "He also never purchased a computer. Eventually, in the la…
There’s no other way to do it for this type of a brain. I know because I have the same type of brain. I spend 90% of my time formulating descriptions of the problem and the desired end state Hallucinating futures where the state of the world is in a state that I either wanted to be or that somebody’s asking me to build Once you know your final end state, then you need to evaluate the current state of the things that…
Lots of interesting threads to chase down but this biographical piece was cool: > together with his wife, he purchased a Volkswagen bus, dubbed the Touring Machine, which they used to explore national parks Maybe not so surprising for a guy who would not indulge in a vcr, cinema, smartphone or even a computer :) more info would be neat if anyone knows from a longer biographic. Photographer? Bird watcher? Hiker? Campe…
You can see the vehicle at https://youtu.be/mLEOZO1GwVc?t=1220 . He and his wife are driving to some sort of camping area. It's part of a longer interview with him. He also does crossword puzzles.
Earlier quoted context omitted.
One of the best remembered, and which led to harmful prejudice against BASIC. While the foundation of the criticism makes sense, it led to silly notions as "there is never a case where GOTOs are useful" and "people who start with BASIC are broken programmers forever"
The problem with unrestricted GOTO isn’t that they’re never useful or that bad people use them. The problem is specifically that they make predicate transformer semantics (and probably other formalisms) pragmatically useless. For example in a language without GOTO inside an if statement the guarding condition is known to be a predicate (at least until another operation changes it) whereas in a language with unrestric…
"At the I F I P Congress in 1971 I had the pleasure of meeting Dr. Eiichi Goto of Japan, who cheerfully complained that he was always being eliminated."
"For many years, the go to statement has been troublesome in the definition of correctness proofs and language semantics....Just recently, however, Hoare has shown that there is, in fact, a rather simple way to give an axiomatic definition of go to statements; indeed, he wishes quite frankly that it hadn't been quite so simple."
I cannot find anything written by Hoare about it, but Knuth goes on to describe it: the idea is that labels have associated preconditions and GOTOs have the semantics { precondition(L) } goto L { false }.
"Informally, a(L) [my "precondition(L)"] represents the desired state of affairs at label L; this definition says essentially that a program is correct if a(L) holds at L and before all "go to L" statements, and that control never "falls through" a go to statement to the following text. Stating the assertions a(L) is analogous to formulating loop invariants. Thus, it is not difficult to deal formally with tortuous program structure if it turns out to be necessary; all we need to know is the "meaning" of each label."
It is a very nice paper. Some sources:
http://www.kohala.com/start/papers.others/knuth.dec74.html
Earlier quoted context omitted.
I think of him more as the Truman Capote of computer science. Backus' characterization of one particular EWD as "bitchy" is right on the money.
Is it? Have you read his EWDs? They're quite interesting and he comes across as far more humble than many people seem to imagine him as. Blunt in his criticism, certainly, but not self-agrandizing or boastful.
The problem is not that he self-aggrandizes or is boastful; it's that he keeps tearing other people down. And that he was very willing to offer sweeping pronouncements on matters that he had no practical experience in. He basically stopped touching computers in the early 1970s, and certainly stopped writing practical programs. What basis then, did he have for dismissing object oriented programming, which for all its flaws has done decidedly more for human progress than program verification has?
And as the tense exchange with Backus shows, he was quick to dismiss the relevance of functional programming, which certainly has done a lot for the kind of mathematical reasoning he advocates for programming (Apparently he taught his students Haskell later. Did he ever apologize to Backus for his wrong headed initial assessment?).
Would computer science miss ANYTHING relevant if he had stopped working in the field in 1975? His output basically consisted of proving propositions over cherry picked toy problems. I don't think anybody doubts that this is possible, but is this a viable approach to build real systems (not only large ones, but also ones whose requirements evolve over time)? I consider this, at best, highly unproven, and yet he advocates this as the sole approach to be taught in CS education. Knuth noted, correctly, that neither Dijkstra's education nor any of the practical systems he built (Algol compiler, etc) were based on this approach.