Talks to Watch

Edsger W. Dijkstra on Dutch TV

45K views · Feb 19, 2014 · 24:05 · 2 HN recommenders · 5 mentions · discussed 2015–2020

A 2001 VPRO Noorderlicht documentary episode, filmed in Austin in 2000, visiting Edsger Dijkstra and his views on thinking as a discipline. It is in Dutch with English subtitles.

Why Hacker News points people here: Recommended as a short documentary that shows the human side of Dijkstra.

“For anyone interested in seeing the human side of Dijkstra, I recommend this documentary”HN comment, 2020

What Hacker News said 5

Recommendswsc981May 2018

“here’s a short documentary on his life and career”

Short documentary on Dijkstra's life and career.

Full comment

Not directly related, but here’s a short documentary on his life and career (Dutch spoken, English subtitles): this video

in “A Short Introduction to the Art of Programming (1971) [pdf]” · view on HN
Recommendswsc981Jan 2019

“a small picture into Dijkstra's life from Dutch tv”

Small picture into Dijkstra's life from Dutch TV.

Full comment

Perhaps not completely related to this topic, but interesting nonetheless, a small picture into Dijkstra's life from Dutch tv (subtitled in English): this video

in “A Bridge Too Far: E.W. Dijkstra and Logic” · view on HN
RecommendsjamezOct 2020

“For anyone interested in seeing the human side of Dijkstra, I recommend this documentary”

Shows the human side of Dijkstra.

Full comment

Good read. For anyone interested in seeing the human side of Dijkstra, I recommend this documentary: this video When I watched it I was both studying Computer Science and learning Dutch, so it was twice as interesting. The version I linked provides English subtitles.

in “Edsger Dijkstra – The Man Who Carried Computer Science on His Shoulders” · view on HN
Cites itjquastMar 2015

“I was duly impressed that they got so many lines of code correct.”

Dijkstra recounts Apollo software errors found by accident.

Full comment

From Edsger Dijkstra: this video > ...just after the first successful moon landing [...] I knew that each Apollo flight required some 40,000 new lines of code. [...] I was duly impressed that they got so many lines of code correct. So when I met Joel, I said, "how did you do that? [...] Getting that software right." [...] He said that in one of the calculations of the orbit of the lunar module the moon had been defined as repelling instead of attracting. They had discovered that error by accident. Imagine, by accident five days before the shot. Sound familiar to anyone? Some 16 years experience myself, the clarity of "the problem of time" has become the foremost factor of bad software that I knowingly write. I imagine NASA has the same problems that we do. I've been through about 5 cycles that all occur in the same form: 1) We put the under-performing developers on maintaining "legacy" systems and the seniors begin on the next one. 2) Time is purposely estimated shorter than viable, corners get cut in the software, prototypes are put into production once again, and a new legacy system is born. 3) The good programmers leave, some juniors become seniors and others are hired, and the cycle repeats. There are many additional mismanagement mistakes that accumulate, but limited time always seems to be at the center of the problem for me. I whole-heartily believe that really great software can be authored by just two or three high quality engineers over the span of a few to many years

in “Things I've learned about writing software after 12 years” · view on HN
Cites itedjrootDec 2018

“the most elegant programs are often the most efficient.”

Dijkstra says elegant programs are often the most efficient.

Full comment

I recently watched a documentary where Dijkstra says the opposite: this video "One of the things I discovered as early as the 1960s is that mathematical elegance is not a question of aesthetics, of taste or fashion, but something you can translate into a technical notion. "The Concise Oxford Dictionary gives as one of the meanings of 'elegant' 'ingeniously simple and effective'. "In practice a program is manageable if you make a truly elegant program, firstly because it is shorter than most alternatives and consists of discrete parts, each of which you can replace by an alternative implementation without influencing the rest of the program, but also, curiously, the most elegant programs are often the most efficient."

in “Efficiency is fundamentally at odds with elegance (2013)” · view on HN