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