The Dutch language quote as displayed: "We mogen niet uit nonchalance fouten in een programma aanbrengen. Dat moeten we systematisch en met zorg doen.".
Feel free to run that through your favorite translator.
The subtitles: "We should not introduce errors through sloppiness but systematically keep them out."
The translator missed a very dry and very Dijkstra joke.
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.
“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.
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)
After almost 10 years working in corporations and in the government, I can't help but think that Dijkstra's call for quality rings truer than ever. It's appaling the amount of projects that get killed not only because they were poorly executed but also because they were completely useless in the first place.
In this day and age we live in a kind of stupor that we have to keep the wheel of economy spinning no matter what and that as long as someone is paying we have to keep sh*tting lines of code for perpetually late projects. It's like we're inefficient on purpose. Look at the shitshow that the SCRUM method is for instance. We are purposefully distancing software development from any kind of rigorous method, it's a real tragedy.
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.
> The courses that Edsger taught regularly all had the title Capita Selecta (selected topics). Prior to his retirement in 1999, the offering alternated each semester between the graduate and undergraduate level. Taking Edsger’s course was an intimate experience and a unique learning opportunity. The class enrollment was limited to 20 or so students, which allowed a rewarding level of interaction between instructor and students. The main form of assessment in his course (in addition to the informal impressions he formed throughout the semester) was a two-hour oral examination, held either in his office or at his home. During this individual session, Professor Dijkstra would present the (usually nervous) student with a problem or two. The student’s task was to develop a satisfactory argument during the allotted time, writing the solution on the blackboard. Afterward, the student would generally leave the room with a warm glow of accomplishment thanks to Edsger’s gentle prodding and questioning during the session.
I was wondering if anyone on HN took his course and could share their experience?
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.
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...
> 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 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.
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.
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.
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.
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.
Writing complete and correct code takes a lot of engineering time and money. The aerospace industry does it and the price tag matches. Imagine how much innovation we would have missed out on if we demanded perfection from every product over the last 60 years
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.
> The management didn't want faultless programs because the company derived its stability from maintenance contracts.
The bane of my existence. Companies like these get a decade long contract with governments and large enterprises (typically outside the "tech" space) to maintain a system, and at the end it's often worse than when they started the contract. Grifters, all of them.
The worst offenders are the defense contractors. They know they don't have to work, sunk cost fallacy is strong in government contracting.
>"The universities will continue to lack the courage to teach hard science, they will continue to misguide the students, and each next stage of infantilization of the curriculum will be hailed as educational progress."
He was complaining of the watering down of curricula in Netherlander unis...
He moved to TX in '84 due to the infantilization of students (by the Dutch). We now have some high school teachers who say they will not issue Ds and Fs and instead will give incompletes only... I'm afraid we have eclipsed the Dutch.
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.
[+] [-] rednab|2 years ago|reply
The Dutch language quote as displayed: "We mogen niet uit nonchalance fouten in een programma aanbrengen. Dat moeten we systematisch en met zorg doen.".
Feel free to run that through your favorite translator.
The subtitles: "We should not introduce errors through sloppiness but systematically keep them out."
The translator missed a very dry and very Dijkstra joke.
[+] [-] noirscape|2 years ago|reply
"We shouldn't add errors to software out of negligence. They should be added systematically and carefully."
[+] [-] TrackerFF|2 years ago|reply
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.
[+] [-] WhitneyLand|2 years ago|reply
“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.
[+] [-] mp05|2 years ago|reply
That's pretty funny, too bad.
[+] [-] jacquesm|2 years ago|reply
[+] [-] raverbashing|2 years ago|reply
[+] [-] lp4vn|2 years ago|reply
In this day and age we live in a kind of stupor that we have to keep the wheel of economy spinning no matter what and that as long as someone is paying we have to keep sh*tting lines of code for perpetually late projects. It's like we're inefficient on purpose. Look at the shitshow that the SCRUM method is for instance. We are purposefully distancing software development from any kind of rigorous method, it's a real tragedy.
[+] [-] elric|2 years ago|reply
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.
[+] [-] shiandow|2 years ago|reply
It will work beautifully though.
[+] [-] usgroup|2 years ago|reply
[+] [-] pncnmnp|2 years ago|reply
https://www.cs.utexas.edu/users/EWD/memorial/newsletterartic...
> The courses that Edsger taught regularly all had the title Capita Selecta (selected topics). Prior to his retirement in 1999, the offering alternated each semester between the graduate and undergraduate level. Taking Edsger’s course was an intimate experience and a unique learning opportunity. The class enrollment was limited to 20 or so students, which allowed a rewarding level of interaction between instructor and students. The main form of assessment in his course (in addition to the informal impressions he formed throughout the semester) was a two-hour oral examination, held either in his office or at his home. During this individual session, Professor Dijkstra would present the (usually nervous) student with a problem or two. The student’s task was to develop a satisfactory argument during the allotted time, writing the solution on the blackboard. Afterward, the student would generally leave the room with a warm glow of accomplishment thanks to Edsger’s gentle prodding and questioning during the session.
I was wondering if anyone on HN took his course and could share their experience?
[+] [-] oluckyman|2 years ago|reply
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.
[+] [-] treprinum|2 years ago|reply
[+] [-] TrackerFF|2 years ago|reply
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...
[+] [-] gregorygoc|2 years ago|reply
> 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.
[+] [-] Icko|2 years ago|reply
[+] [-] nerdponx|2 years ago|reply
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.
[+] [-] bruce343434|2 years ago|reply
[+] [-] usgroup|2 years ago|reply
[+] [-] vsnf|2 years ago|reply
[+] [-] sebstefan|2 years ago|reply
Alan Kay said it best
"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."
[+] [-] pythonguython|2 years ago|reply
[+] [-] Jtsummers|2 years ago|reply
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.
[+] [-] fransje26|2 years ago|reply
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.
[+] [-] Jtsummers|2 years ago|reply
The bane of my existence. Companies like these get a decade long contract with governments and large enterprises (typically outside the "tech" space) to maintain a system, and at the end it's often worse than when they started the contract. Grifters, all of them.
The worst offenders are the defense contractors. They know they don't have to work, sunk cost fallacy is strong in government contracting.
[+] [-] NavinF|2 years ago|reply
[+] [-] mc32|2 years ago|reply
He was complaining of the watering down of curricula in Netherlander unis...
He moved to TX in '84 due to the infantilization of students (by the Dutch). We now have some high school teachers who say they will not issue Ds and Fs and instead will give incompletes only... I'm afraid we have eclipsed the Dutch.
[+] [-] NavinF|2 years ago|reply
Seems fine to me. Grades have always been totally arbitrarily. Just look at test scores instead
[+] [-] nerdponx|2 years ago|reply
[+] [-] vlowrian|2 years ago|reply
[+] [-] o2l|2 years ago|reply
[+] [-] noitanec|2 years ago|reply
[+] [-] jacquesm|2 years ago|reply
https://en.wikipedia.org/wiki/Formal_verification
[+] [-] pieterr|2 years ago|reply
[+] [-] zubairq|2 years ago|reply
[+] [-] morphle|2 years ago|reply
[+] [-] esafak|2 years ago|reply
[+] [-] DrDroop|2 years ago|reply
[deleted]
[+] [-] fancyfredbot|2 years ago|reply
[+] [-] DrDroop|2 years ago|reply
[deleted]
[+] [-] mp05|2 years ago|reply
[deleted]