Edsger W. Dijkstra on Dutch TV

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.

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

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

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

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