http://web.archive.org/web/20090320002214/http://www.ecn.pur...
Current languages mostly don't even allow the bad kinds anymore, so people can ignore history, and complain that "goto isn't so bad, I've never seen anybody abusing it like he claims in the essay."
The empirical approach would be to compare outcomes of different approaches, trying to control the independent variables.
But CS instead seems to be run by polemic, "Well, obviously..." rhetoric, and tribal affiliation.
I've yet to be convinced this is the ideal way to improve the tools and techniques of CS.
People usually present his work in terms of proofs only. Typically with big O considerations. Reading him, he very quickly warns of the dangers in big O analysis. (He is still a fan of it. Encouraged it as a math aid for grade school work, at one point.)
Do you have a link / some elaboration?
But TL.DR. - He got digged plenty of repeating cases of bad code, and proceeded to fix every one of them with very few coherent and systematic changes.
1 - His notes are here: http://www.cs.utexas.edu/users/EWD/ unfortunately, I don't remember what numbers to look.
But we do teach them that. As a result I recently had to review changes made by a (very capable) junior colleague who failed to actually implement the desired feature, but did get so upset by the goto-based error handling that he replaced it with incorrect exception-based code.
When teaching a language that support bad gotos, or compilers. Otherwise, you can count a lot of people (including me) out of that undefined "we" pronoun.
There's little point in teaching newbies about goto at all. The few modern implementations are for experts, because it can still lead to some bad code, just not the kind of "bad" Dijkstra was talking about. Yet there's a group of people that will evangelize about any subject you can think about, normally people with very shallow knowledge on the subject.
(https://m.facebook.com/story.php?story_fbid=1015411943840422...)