Dijkstra's interview on Dutch TV (2000)

As a native dutch speaker here's how I would translate it:

"We shouldn't add errors to software out of negligence. They should be added systematically and carefully."

"We should not introduce errors into a program out of carelessness. We must do this systematically and with care."

That's pretty funny, too bad.

From your comment it sounds like Gpt-4 got it?

“We must not introduce errors into a program out of carelessness. We must do it systematically and with care.”

Dijkstra’s statement appears to be a bit of dry humor. He’s known for his wit and often used irony in his statements. The idea of deliberately and carefully introducing errors into a program is clearly absurd, which is the joke. It’s his way of emphasizing the importance of being meticulous and systematic in programming to avoid errors.

As a Norwegian, I always found Dutch interesting. It is just close enough, that I can read it and get the gist of the message, without actually knowing Dutch. It is much easier than, say, German.

I read the message as: "We must not carelessly introduce errors to a program, but rather systematically and with care"

The joke being that we introduce the errors systematically and with care.

That's hilarious. I think the translator may have decided not to want to confuse the audience with the Dutch sense of humor.

I don't think the translator necessarily missed the joke, but had to fit the phrase in the available space (which is an issue when subtitling and an even bigger issue when dubbing)

No amount of mathematics is going to prevent you from making something nobody needs.

It will work beautifully though.

Scrum is not an acronym, there's no need to write it in all caps.

Scrum is not intended to remove rigour from development. It acknowledges that people (the client) have no clue what they want (they're no Mozart), and that it's up to the development mean to help them figure it out. Ideally converging on something that the client wants, and works well.

Sure, plenty of projects fail for a variety of reasons. And sure, scrum (or agile in general) isn't perfect. But it's the best tool in our toolbox at the moment.

You, and all those other folks who like to tilt at the scrum windmill, are more than welcome to propose something that works as well as (or better than) scrum without the downsides. But so far, it's been crickets.

IMO there are three big issues: clients don't understand software development, and management doesn't understand software development, and software developers neither understand clients nor management.

This rings true in my experience too. It isn't even artisanal code lacking an end user, its garbage code that barely works which no-one wants. Luckily I've spent most of my time in the start-up space where things working is a more existential concern, and the sort of thing mentioned above is less of a problem.

I was a visiting professor there in 1989, and sat in on the course, which was on math proofs. We had weekly homework, which I did. In one class, I told Dijkstra that his proof was wrong. He couldn’t see my point, and we argued briefly and agreed to disagree. It was the only time anyone spoke up in class without being asked to by Dijkstra. At the start of the next class, Dijkstra announced that his attempted proof was indeed wrong, and proceeded to give a revised proof. Everyone was impressed by his intellectual honesty. He wrote up the episode as EWD 1044 https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...

Dijkstra asked me to sit in on one final oral exam which he was expecting to be tricky. It was a very intimidating atmosphere for the student.

I feel you should be able to keep the high level idea in your head at once; of course not the details. I don't think I've ever completed a piece of code without having a scheme in my head, and where it should fit in it.

Dunno, maybe it's some old-school thing from the days of punch cards?

My first programming teacher was back in HS, some 25 years ago. The man was a retired software engineer in his 60s. He really pushed that train of thought - to "finish" the code in your mind, on paper, etc. before actually writing it and hitting compile / run.

I never took it literally in the sense that you need to think out the entire program, but rather that when writing functions and more overall logic, it is good practice to have it all worked out - rather than just write as you go, and iterate. The latter part is very easy to do these days, as running code is more or less instant...

My father, a programmer who got his start in the punch card era, was the same way, but I never had the mental capacity for this. I need to start writing before I can concretely hold anything in my mind. The structure of the program, and the output feedback loop into themselves and emerge more or less simultaneously.

I liked some of the MIT lisp lectures where they show that you compose a program out of simple functions. Think of the input, the out, and then a made up function which transforms it in 2 to 5 made up steps. Then recurse, and think of steps for the steps. Etc.

This is not what he said.

> There are very different programming styles. I tend to see them as Mozart versus Beethoven. When Mozart started to write, the composition was finished. He wrote the manuscript in one go. In beautiful handwriting, too. Beethoven was a doubter and a struggler, who started writing before he finished the composition and then glued corrections onto the page.

I get this now but certainly didn't 20 years ago, and I suspect it will more easily register with functional/logical programming language users. I've heard it referred to as "wholemeal" programming. Take the first step with the last one already in mind, and be circumspect. In practice you still iterate, but a lot less, and pursuit of this ideal does result in a different aesthetic to the solution. I personally have a fetish for short code with minimal departures from the standard library. I "feel" it when its correct, and this strongly conditions how I code as a result.

I've never regretted spending time up-front on architecture and design. Of course you aren't going to write the entire program from scratch in your head. But iterating through stages of written descriptions, diagrams, actual code, and unit tests tends to produce a much higher quality result in the end than just banging out and implementation from start to finish. It takes more time at the beginning, but it takes so much less time to clean things up later that the additional time cost at the beginning is usually worth it.

Writing prose is similar. it might seem like you don't want to waste time outlining and sketching out ideas, but it's usually easier to assemble something useful from an outline than it is to try to work with a disjointed stream of consciousness.

You might get to a point of familiarity and/or mastery where you can do a lot of that work in your head. But that's very different from not doing that work at all.

The aerospace industry does not write complete and correct code. Hate to terrify you, but it's true. Some companies do, some specific areas do. Most are just a step or two above the software industry average in terms of quality, which is not that stellar.

They don't get there by using a lot of formal methods or thinking deeply. They get there by testing the shit out of everything and static analysis tools (which have gotten a ton better since I started in the industry). Some of the programmers I've had to clean up after were mediocre, at best (though others were stellar). The main reason their systems don't kill people is the testers standing between you and their original code.

MBSE has been picking up, and it's a good thing. It's not as big as it should be or always used effectively, but it's helping.

> Imagine how much innovation we would have missed out on if we demanded perfection from every product over the last 60 years

Very ironic to have such a take when the very industry brought up is arguably the one that brought the most innovation of the post-war era. From metal alloys to electronics, plastics, composits, wireless transmission, precision machining, quality standards and traceability.

Not all defense contractors use cost-plus contracts

> they will not issue Ds and Fs and instead will give incompletes only

Seems fine to me. Grades have always been totally arbitrarily. Just look at test scores instead

Those high school teachers are, just like everyone else, primarily individuals responding to the incentives and costs with which they are presented. Infantilization might be a long-term symptom, but don't make it sound like creeping moral degradation is an underlying cause.

That's where formal verification comes in.

https://en.wikipedia.org/wiki/Formal_verification