My point today is that, if we wish to count lines of code,
we should not regard them as "lines produced" but as "lines
spent"Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
21–30 of 64 posts
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#22It's interesting to see how attitudes to this EWD have changed over the years. Here are some of the previous submissions with comments:
https://news.ycombinator.com/item?id=43978 : A few comments
https://news.ycombinator.com/item?id=1666445 : Many comments
https://news.ycombinator.com/item?id=3553983 : Many comments
In the earlier threads there are two main voices: "Where can I learn more about this," and "It's useful to see the different perspective." Both say that there are many nuggets of wisdom to be mined, even when they don't agree. There are also a few who dissent and say it's irrelevant, impractical, and inapplicable.
Even in 3553983 where the top comment says it's largely irrelevant there is a useful dialogue discussing the ideas, and how they can be made to work, or at least how we can learn from them in today's context.
In contrast, in this thread so far we've mostly had comments about the hand-writing, and complete dismissal of the ideas. So far there's very little attempt to say: "OK, times have changed, but can we learn something from this?"
So I ask - Can we? Are there nuggets to be mined? Or are you convinced that you really do know better, and have nothing to learn from it.
I'm still learning.
========
For reference, other submissions, mostly without comments:
https://news.ycombinator.com/item?id=6701607
https://news.ycombinator.com/item?id=2122826
https://news.ycombinator.com/item?id=2090256
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#23I think people are attracted more to the form of the EWDs and to it's melancholic tone, rather than to the content itself, which is confirmed by the huge popularity of the EWDs as compared to "The discipline of programming", which is the technical exposition of what Dijkstra really is proposing in the EWDs. As almost all of Dijkstra's writing, this piece here is a plea for teaching formal methods. It's nicely written…
But, however much you might bristle at his tone, he has something significant to say, and he's right when he says it. You can't take this paper (or any other) as an end-all/be-all statement isolated in a vacuum. Maybe his smug tone portends that he might presume as much, but it's a mistake to take it as a one-size-fits all remark. The thing he gets right is this: Teaching students "Computer Science" as a new discipli…
I can't agree with this either. Practical engineering is not pure mathematics, and once systems get complex enough, even if they are man-designed and not given from nature, there is often no other way than to use "reverse engineering" or in other words use empirical methods to understand some behaviour or fix a problem.
In fact, one of the most important skills to learn for prospective computer programmers is rigorous design of experiments to confirm or deny a given thesis about some aspect of a given system. When you are dealing with a virtual machine on top of an operating system, communicating over a network through tcp/ip with another virtual machine, there are millions of lines of source code involved, not to mention potential hardware issues, how can anyone be expected to understand all of it? Even if some of this complexity is accidental, as soon as we get rid of it we will just build more sophisticated systems, so people will regardless have to know how to deal with systems that do not fit in ones head all at once and where you can't always just reason your way out.
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#24Earlier quoted context omitted.
But, however much you might bristle at his tone, he has something significant to say, and he's right when he says it. You can't take this paper (or any other) as an end-all/be-all statement isolated in a vacuum. Maybe his smug tone portends that he might presume as much, but it's a mistake to take it as a one-size-fits all remark. The thing he gets right is this: Teaching students "Computer Science" as a new discipli…
I can't agree with this either. Practical engineering is not pure mathematics, and once systems get complex enough, even if they are man-designed and not given from nature, there is often no other way than to use "reverse engineering" or in other words use empirical methods to understand some behaviour or fix a problem. In fact, one of the most important skills to learn for prospective computer programmers is rigorou…
Whoa, you jumped to some conclusions at the end there that just don't add up. Since how is formalizing something counterproductive to building sophisticated systems?
The systems you mentioned were actually built in a non-formalized matter (further emphasizing the OP if anything). Of course it is incredibly difficult to build even more sophisticated systems on top of these systems for that very reason. Many of them are needlessly complicated leaky abstractions - but persist due to industry inertia.
The methods you describe are exactly the problem causing this.
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#25Earlier quoted context omitted.
I can't agree with this either. Practical engineering is not pure mathematics, and once systems get complex enough, even if they are man-designed and not given from nature, there is often no other way than to use "reverse engineering" or in other words use empirical methods to understand some behaviour or fix a problem. In fact, one of the most important skills to learn for prospective computer programmers is rigorou…
Whoa, you jumped to some conclusions at the end there that just don't add up. Since how is formalizing something counterproductive to building sophisticated systems? The systems you mentioned were actually built in a non-formalized matter (further emphasizing the OP if anything). Of course it is incredibly difficult to build even more sophisticated systems on top of these systems for that very reason. Many of them ar…
You are misunderstanding and/or misrepresenting my point, which is that once enough people over a long-enough period build systems in a top-down, systematic matter, well as it works, it becomes impossible for a single person to understand a specific issue about a stack of such systems, especially once the real-world kicks in with hardware issues, bugs, and so forth, in which case you have to resort to methods that do not require keeping all relevant aspects in the head and that do not rely on the truth of idealized assumptions. Like in going from mathematics to physics, in real-world software engineering is no longer sufficient for conclusions to follow logically from the premises, since the premises now also have to be true in the real world conditions. Having non-leaky abstractions only shifts the moment in which the shift from pure thought to empiricism has to happen.
It seems to me that you actually use the notion of being "formal" in an informal (sic) way. Remember we are talking about Dijkstra-style correctness proofs and developing programs via doing mechanical in nature transformations of program invariants.
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#26I know Dijkstra's genius and all, but his papers are just so unpleasant. First, I hate his verbose style and second, I hate his attitude. "The effort of using machines to mimic the human mind has always struck me as rather silly. I would rather use them to mimic something better." Jesus, could he be any more smug?
Depends on how you read it. You could mimic structures from society or nature. The isolated human mind is quite a useless thing.
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#27A wonderful read from a badass scientist. Here is a good nugget of wisdom:
Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot".
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#28Earlier quoted context omitted.
Whoa, you jumped to some conclusions at the end there that just don't add up. Since how is formalizing something counterproductive to building sophisticated systems? The systems you mentioned were actually built in a non-formalized matter (further emphasizing the OP if anything). Of course it is incredibly difficult to build even more sophisticated systems on top of these systems for that very reason. Many of them ar…
You are misunderstanding and/or misrepresenting my point, which is that once enough people over a long-enough period build systems in a top-down, systematic matter, well as it works, it becomes impossible for a single person to understand a specific issue about a stack of such systems, especially once the real-world kicks in with hardware issues, bugs, and so forth, in which case you have to resort to methods that do…
I am not convinced that in order to use the methods described one would have to keep the entire "world" in their head. In fact, I think these methods would actually help manage that problem rather than exacerbate it.
In the end a software program is and always will be an approximation of the real world.
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#29I think people are attracted more to the form of the EWDs and to it's melancholic tone, rather than to the content itself, which is confirmed by the huge popularity of the EWDs as compared to "The discipline of programming", which is the technical exposition of what Dijkstra really is proposing in the EWDs. As almost all of Dijkstra's writing, this piece here is a plea for teaching formal methods. It's nicely written…
"it is also unbelievably smug and disconnected from reality." - it's funny how he addressed your objection as well
Re: Dijkstra: On the cruelty of really teaching computer science (1988) [pdf]
#30It's interesting to see how attitudes to this EWD have changed over the years. Here are some of the previous submissions with comments: https://news.ycombinator.com/item?id=43978 : A few comments https://news.ycombinator.com/item?id=1666445 : Many comments https://news.ycombinator.com/item?id=3553983 : Many comments In the earlier threads there are two main voices: "Where can I learn more about this," and "It's usefu…
The audience is self-selected. The ones that don't know any better see only a condescend tone instead of the material. They don't get the difference between "lines spent" and "lines produced" and they don't know that computers were used to "compute" and thus the formalism was absolutely necessary to trust the result.
What we write today is WoW and stuff we don't need formalism to prove they don't crash - because, you know, who cares about that?
Dijkstra comes from a time were you could reuse a piece of software and build upon it because you could understand it. Today nobody does it because the software is "disposable". Who cares about proving a piece of future garbage?