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.
There is something about Norwegian that makes it more easy to understand than any other Germanic language (besides English I guess, but that's just because we're broiled in it from early age). It somehow stayed more close to the shared Germanic than German itself?
Also: most Norwegians have very little accent when speaking English, unless they're in some kind of satiric Viking series.
Was watching Bron/The Bridge some time ago. Danish sounds like gibberish indeed, but then again "We hebben een serieus probleem" was a meme a little while back.
Dutch and Danish share heritage via Frysian and Saxon (English) heritage. IIRC the Frysian lived among the whole coast of North Sea from Holland till North-West Germany, and then enclaves in Denmark, too.
Dutch is a Franconian dialect though? They just didn’t go through the consonant shift like their cousins in the Rhineland. It isn’t really that closely related to Frisian or Low German and even less so to Norther Germanic.
It's called being mutually intelligible, which is when languages share enough words/sentence structure that you can understand the meaning of a sentence even if you can't directly translate it.
How much German do you know? As a Norwegian Dutch is completely Greek to me. I did take German in school although none of it stuck besides some pointless(in isolation) grammar rules.
Also Norwegian, and I'm with the person above, but I think it depends a lot on your Norwegian dialect, maybe? The more towards conservative bokmål you get, or even exposure to older Danish, the easier both Dutch and German gets. I think reading a lot of pre-WW1 novels helped my German quite a bit.
I'll note the biggest reason why Dutch may seem somewhat closer than modern German is that modern German is mostly High (Southern) German. Low German common in the Northern parts of Germany before lies closer to the continuum between Dutch and the Scandinavian languages (for example it didn't got through the same consonant shift and still has Dag for day/dag instead of Tag).
There are many words in Dutch that you might recognize as similar to Norwegian that you might be marginally more likely to fail to recognise in modern German because the spelling is slightly more different.
> is that modern German is mostly High (Southern) German
Absolutely not. South german is for me Badisch, Schwäbisch, Bayrisch und Alemannisch (Badian, Swabian, Bavarian and Alemmannian --- similar to Swabian, but with lots of differences, e.g. we have "gwä-Schwaben" und "xsi-Schwaben".
But perhaps my other understanding stems from the fact the "Hochdeutsch" (high german) can mean different things. E.g. the german wikipedia has a disambiguation page https://de.wikipedia.org/wiki/Hochdeutsch for it.
I interpreted it to be the "normal" german we all speak if we don't speak a german dialect. Or, in other words, the first link of that disambiguation page: standard german. And that is a result of some "norming process", initiated mostly by the brothers Grimm, i.E. they wrote the first generally accepted german dictionary. Generally we can say that this process started in the 17th century, with it's high in the 18th. So it's quite modern, long after dialects formed.
And they didn't life and work in southern Germany, but quite in the center, the area between Hanau and Göttingen. If we look for dialects there, when we see that they are influenced by frankonian and saxonian dialect --- not the modern day Saxonia, but the historical one. The border between both empires goes right through the working area of the Grimms, e.g. the german town "Frankfurt" has a "Sachsenhausen" at the over side of the river. Or north of Marburg you have "Frankenberg" and "Frankenau" but also "Sachsenberg" and another "Sachsenhausen". These old kingdoms created language differences ... but they have nothing to do with southern german dialects / languages.
However, the various "Plattdeutsch" dialects like Plattduitsk or Frisian are totally different, here you're correct. They are categorized usually as "lower german" (Platt => flat => lower), North See Germanic, West Germanic, Germanic, Indogermanic.
From my perspective South of the North sea coast is South ;) I'll agree it's not precise, but both links on the disambiguation page to my eye justifies my use of it, at least in this context.
I'm certainly willing to accept that there may well be significant aspects of standard German that incorporates more central and Northern dialects and deviates from the southern Hochdeutsch dialects in ways I have no idea about. I'm sure you know far better than me about that.
But the most relevant differences in the context of my comment was the High German consonant shift, the effects of which is one (of several, sure) big change separating Standard German from the other Germanic languages, and which was mostly firmly happening further South than Plattdeutsch/Niederdeutsch/Low German.
In that respect at least, standard German orthography is closer to that of South/Hochdeutsch, and it has separated German further from the rest of the Germanic languages.
E.g. compare:
* Day: dag (Scandinavian, Dutch), Dag (low German languages), Tag Standard and High German.
* Ship: skip (Norwegian, Swedish) , skib (Danish), Skip/Schip/Schipp/Schepp (various lower German variants, Frisian), Schiff (Standard and High German)
* Apple: eple, Appel, vs. Apfel
* two: to (Norwegian, Danish, två (Swedish, Norwegian dialects), twee (Dutch, lower German), zwei (Standard and High German)
The point is that Dutch has a lot of features that is shared with both low German and Scandinavian languages but that has disappeared from modern standard German, not that it has always been more similar to low German than to other German dialects.
E.g. like low German and most of the other West and North Germanic languages, Dutch did not go through the High German Consonant Shift, but modern standard German "imported" that.
That makes modern German a lot harder to read for Scandinavians in ways that Dutch simply isn't.
I often find it easier to read Dutch despite never having learnt it than I find reading German despite having had three years of German lessons in school.
And if you start digging into the shared vocabulary between Dutch and the Scandinavian languages, you'll find a whole lot of those words are words that have retained far more similarity to the low German dialects than the Scandinavian languages have to standard German.
See also my other comment on this, with some comparisons.
Note that this does also not necessarily go both ways - I'm totally willing to accept that you might find high German more similar than low German from your perspective because of different subsets of shared vocabulary or structure, for example.
“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.
If you think that it's the role of a developer to figure out what a client wants, then well... We have completely divergent views of how the the process should be. A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product.
It's not that scrum is not perfect, scrum is an absolute garbage that unfortunately today fits very well with the micromanaging hunger of managers, no method is better than scrum.
> A software developer should develop for a specification, he or she should not be there to entertain clients in a game of creating a product.
That's a sad view. Reminds me of a couple past managers I've had who thought that software developers were assembly line workers.
US culture note: The cultural expectation for assembly line workers here is that they "shut up and color", it's the job of the managers and engineers to do the thinking. That is, even if an assembly line worker can see that something is wrong, it's not their job to point it out or fix it. They are disempowered in this culture.
What's sad about your view is you similarly want to disempower developers. You don't want them to have input into what they're making, you just want them to shut up and code. According to you the specification is, what, always given to the developers without their input? So if the specification is non-viable they should just accept it and sit in their corners making nonsense?
I'm not saying that developers should ideally be drones who have no say on anything. I'm just calling bullshit in the ADHD-fueled development of nowadays where people are not even sure about what the final product should look like and put on the shoulders of the developers the workload of dealing with the ineptness of the clients and the managers.
Scrum nowadays is essentially a tool for micromanagement, that's why managers love it and developers hate it. Dailys are completely useless and breaking the development of complex projects in 2 weeks sprints is outright harmful.
> calling bullshit in the ADHD-fueled development of nowadays where people are not even sure about what the final product should look like
Sigh. Of course people aren't sure about what a final product should look like. It's easy enough for something small, but once something gets big, how the hell are people expected to know how everything will work up front?
> Scrum nowadays is essentially a tool for micromanagement, that's why managers love it and developers hate it. Dailys are completely useless and breaking the development of complex projects in 2 weeks sprints is outright harmful.
Sure, some managers love scrum, and some developers hate it. But it's not a tool for micromanagent. It's a tool for course corrections in the face of reality.
I personally find dailies to be very useful, especially in a distributed team. It's an efficient way of figuring out what's up and making sure all noses are pointed in the same direction.
No managers are involved in any of my day-to-day scrum ceremonies.
If your manager hits you with a hammer, you might want to consider that your manager is an arse instead of blaming the hammer. When a tool doesn't work for you, sometimes it's not the tool that's to blame, but the larger context in which the tool is being used.
> A software developer should develop for a specification
Really? And where does this specification come from? Presumably from a bunch of analysts? Who then write a big fat document? Which is then handed over to developers, who then groan because it is incomplete, unclear, unusable, or unrealistic? This sounds an awful lot like the waterfall of yore which turned out not to be all that great.
> he or she should not be there to entertain clients in a game of creating a product
The client tends to pay people with the hopes of getting a working product. It should absolutely be the developer's job to ensure that they get it. Even if that means -- shudder at the thought -- talking to them.
Pedantry on my part, but would you say that a non-existent unicorn weigh some amount "None"? That'd be strange to me, and "no amount" would describe such a situation.
That hypothetical has very little to do with the situation at hand. Badd software clearly exists and it is possible to talk about how much mathematics went in it. If no mathematics went in that's still an inidication of 'how much' and therefore is an amount.
"A non-existent amount of mathematics" -- which the joke could have been interpreted as implying -- is not zero mathematics: that would be an existent amount.
Another place these semantics arise is in talk about probability and possibility, wherein the possible can have zero probability (e.g. any specific value in a continuous probability distribution), but the impossible cannot have a zero probability because by definition it is outside the set of "possible events" (measure theoretically). Both make little intuitive sense.
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...
The edit-compile-test cycle in 1986 on a large mainframe was approximately 6 hours. A laser printer cut that down to 3.5 hours and that was enough to be able to do twice as much in a day. You can't imagine how surreal the difference was between my productivity at home on my micro computer vs what I got paid for.
The only way to get anything done at all was to have the program more or less complete in your head otherwise you'd be busy for months on a simple problem. Exploratory programming? Forget about it...
> 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.
He did say that having successive revisions is doing it wrong. Literal quote (from the translation)
"So then you get these version numbers, even with decimals, version 2.6 or 2.7. That's nonsense. While version 1 should have been the finished product."
So I think the nuance you are trying to make is unsupported. He did mean: think it through once, write it out once, version 1. Done.
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.
I'm pretty sure you have the mental capacity, you just don't have a concrete need for doing it that way. It's like having the capacity to walk from here to Paris (wherever you are, pick a large city a few hundred km away). You can do it. But you never will and so you won't know that you actually have that capacity.
But if the real need arose and you had no other alternatives suddenly the impossible would be possible.
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.
I don’t consider it ironic. My opinion is that both fast paced development and careful rigorous development can produce innovation, but often of a different kind. You can have both and they don’t have to negate each other. The development pace at companies like Google have contributed to changing the world just like NASA has
> 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.
I have, unfortunately, seen this behavior and outcome with many types of government contracts, not just cost-plus. One of the worst had the contractor so deeply embedded in a program office the IG got involved as they were receiving incentive payments despite failing to meet contract requirements (despite several government people losing their positions, the contract was not lost even though fraud had almost certainly occurred).
There are certainly some contractors who aren't as deep into the grifting, and a small handful who really are sincere, earnest, and successful, but they're a rare breed. The big contractors (Raytheon, LM, NG, Boeing) keep eating up the little ones, and the outcome is about what you'd expect from these conglomerates.
I had an employer that would do 10% margin on cost plus. Fixed price they would shoot for 300% or 400%, and if they were getting close to losing money they would start begging for more before delivery. They only time they really lost money is when they were trying to get into a new line of business and wanted to build heritage.
If they ever needed to compete on price, they just wouldn’t. Usually their competitors wouldn’t either, there were only a few.
>"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.
So why are they inflating As if grades don't matter and are arbitrary (I don't think they are). The A kid knows a whole lot more than the kid with Ds. Or put another way, for most knowledge economy jobs, I would prefer hiring unwatered straight A students over straight D students. If I needed burger flippers or landscapers, I probably would prefer straight D students --they just want to get their job done, few questions asked, and you let them bitch about the job and the economy.
Does anyone here think China is going to water down their education and risk their competitiveness in hard sciences and maths?
I meant that grades have a low correlation with both general intelligence (g factor) and performance on specific jobs like software engineering.
> why are they inflating As
Because some people still think that grades matter
> The A kid knows a whole lot more than the kid with Ds
Sure but you can figure that out with just one leetcode question. After taking LC performance into account, there are ~0 bits of information left in grades
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.
When you're arguably an s-tier genius you can get away with it. Truth be told, I'm suspicious of very, very smart people who aren't acutely aware of it.
Besides, did we not all just share a hearty chuckle over Linus Torvalds' astounding arrogance just a few days ago?
Just think at how backwards your comment is, basically you are telling me to shut up because you are a good boy who listens to his operations research professor in school who thinks that the only thing that matters for being validated as a human is having something named after you. Like does your professor have a foundational algorithm in computer science named after him? Does he? Why do you care what this smuck thinks, why should I care what you think. Dijkstra said some demonstrably invalid things about the process of software development and I am right about pointing that out without any reputation of degree to speak off.
Both of you broke the site guidelines so badly in this thread that you crossed the line at which we'd ban an account. I'm not going to ban you now because your account has also posted good things, but if you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules in the future, that would be good.
Please particularly avoid tit-for-tat spats. They are never interesting to read, and they degrade discussion badly.
Both of you broke the site guidelines so badly in this thread that you crossed the line at which we'd ban an account. I'm not going to ban you now because your account has also posted good things, but if you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules in the future, that would be good.
Please particularly avoid tit-for-tat spats. They are never interesting to read, and they degrade discussion badly.
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.