No acknowledgement that the other side of the tradeoff might have some great merit in the software correctness argument, even when discussing accomplishments as great as putting a guy on the moon on a tight schedule. And throw in there something about pretending not to understand what "lines of code" means.
I don't think he meant to say it is unclear what 'line of code' stands for, but rather the correct observation that it may mean very different things depending on the programming language involved, and the problem being solved.
What is this "other side of the tradeoff" you speak of? Should there have been such a tight schedule in putting a man on the moon? I think you might have an argument about software development in general, where the standards do not need to be this high all the time, but in the case of the moon landing it's hard to argue for loose standards when human lives are at stake. It's rather disconcerting they admit they just got lucky, in terms of software correctness.
There is always a tradeoff, even for projects where lives are at stake. We do not have infinite time or resources. Nobody but you used the term "loose standards"; the argument is that all projects involve a tradeoff between speed and correctness, even when some demand more of the latter and less of the former.
That's the standard narrative and parroting it over and over again doesn't really make it true. Arguments over correctness almost always devolve into a shouting match because no one ever defines what they mean by it. For your standard consumer application a notion of correctness doesn't even exist so the argument is moot there. You have to narrow your domain a little bit to actually start talking about it. You have to get down to the level of protocols and interfaces and other mathematical beasts where correctness actually means something.
The standard example of correct software and in fact where most work on formal correctness tends to happen is in compiler design and distributed systems. So when you say that there is a tradeoff between speed and correctness that is simply not true. All those compilers you use are correct, for a very precise definition of correct, and fast and constantly improving.
We weren't arguing about formal correctness, so I can only assume you have stumbled into the wrong thread. We were discussing whether safety-critical software still involved a tradeoff between lacking bugs (or "errors" as Dijkstra would prefer calling them) and getting finished on time ("speed" in the development sense, not in terms of runtime performance like you seem to have assumed).
I appreciate your concern that a shouting match was imminent, but with gems like "running your mouth" and "parroting it over and over again" I think, ironically, the only one risking that is yourself.
Beware of bugs in the above code; I have only proved it correct, not tried it.
- Donald Knuth
Formal correctness and implementation correctness are still separate issues in compilers like gcc but that doesn't change the fact that there are correctness specifications for gcc. There are projects that try to bridge the gap: https://en.wikipedia.org/wiki/CompCert.
That's a rather lame quip. I still don't know what the tradeoff is. Dijkstra wasn't asked to do that, and just because the other guy did it once doesn't make his software methodology superior.
The point is that the other side of the tradeoff (of COURSE we would like things to be correct as they can be) is getting it done. I question that this is not somewhat obvious.
What makes you think correctness was not a priority for the software that put a man on the moon? If you actually look a the history and how the software was actually written there is no doubt that correctness was a top priority. It even had facilities that a lot of modern software lacks: self-correction. Before running your mouth you should read the actual history: http://en.wikipedia.org/wiki/Apollo_Guidance_Computer. Not being up to Dijkstra's standards is a different matter altogether.
He is right about one thing. Elegance and correctness require a certain level of intelligence and sophistication that the average software developer lacks.
> What makes you think correctness was not a priority for the software that put a man on the moon?
I reread what I wrote and I honestly don't know why you'd want to attribute that belief to me. Not acknowledging all the priorities in the correctness tradeoff was something I was writing against. Not counting correctness as a priority would certainly qualify.
I've always found NASA discussions of software quality to be interesting and informed by practical experience.
> Before running your mouth you should read the actual history
I've read a few of Dijkstra's EWDs, and his letter to the UT Budget Council re. their decision to switch from Haskell to Java for freshman programming. He always came across as someone who wrote with a very high signal/noise ratio.
Turns out even his speech was like that as well! I was eagerly absorbing every word.
If anyone speaks dutch here, you should view the Video reports that Tweakers did some time ago about Dutch people in US. For ex. About Java founder Arthur van Hoff http://goo.gl/qlEPYX
And many others (you can find the other ones in the right sidebar with : "Gerelateerde inhoud")
It's actually a very interesting video-series about designers at Apple or UX experts at Adobe for example. And more importantly, how they got there.
>"We should not add bugs to a program out of nonchalance. We should do so systematically and with great care".
The translator translates this to
> "We should not introduce errors through sloppiness, but systematically keep them out",
which I found unfortunate, since it completely loses the original meaning.