[marcosdumay]

That's because the original Dijkstra argument was part of a research line that created structured programming. The essay (and the other papers) has really nothing against the usage on that your first link. The real problem was goto into loops or subs, not out of them, and not as switch statements.

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

[adrianratnapala]

If the bad kinds of `goto` aren't even allowed by compilers any more, then there is precious little to be gained by teaching youngesters that gotos are bad.

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.

[marcosdumay]

> But we do teach them that.

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.

[TheOtherHobbes]

It's curious how unempirical these debates are.

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.

[taeric]

This is actually the main thing I like about Knuth. Things are either proven, in very strict terms, or they are empirically studied. Also typically in rigorous means.

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

[jacobolus]

> Encouraged it as a math aid for grade school work, at one point.

Do you have a link / some elaboration?

[taeric]

Apologies for not seeing this yesterday. I believe this is the link. http://www-cs-faculty.stanford.edu/~uno/ocalc.tex

[marcosdumay]

I recommend anybody to look at Dijkstra's notes on structured programming¹. It's a very worth teaching on how to conduct impartial research and transform a field of knowledge.

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.

[eli_gottlieb]

http://dl.acm.org/citation.cfm?id=2851730