Earlier quoted context omitted.
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.
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.…
Vigorous Public Debates in Academic Computer Science
31–38 of 38 posts
Re: Vigorous Public Debates in Academic Computer Science
#32Earlier quoted context omitted.
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.…
> Encouraged it as a math aid for grade school work, at one point. Do you have a link / some elaboration?
Re: Vigorous Public Debates in Academic Computer Science
#33While not exactly a debate -- more of a fundamental difference in outlook -- these are interesting, completely opposite claims: Bob Harper[1]: > There is an alternative… without… reference to an underlying machine… [W]e adopt a linguistic model of computation, rather than a machine model, and life gets better! There is a wider range of options for expressing algorithms, and we simplify the story of how algorithms are…
Re: Vigorous Public Debates in Academic Computer Science
#34Earlier quoted context omitted.
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 is…
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 except…
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.
Re: Vigorous Public Debates in Academic Computer Science
#35Earlier quoted context omitted.
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 is…
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.
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.
Re: Vigorous Public Debates in Academic Computer Science
#36While not exactly a debate -- more of a fundamental difference in outlook -- these are interesting, completely opposite claims: Bob Harper[1]: > There is an alternative… without… reference to an underlying machine… [W]e adopt a linguistic model of computation, rather than a machine model, and life gets better! There is a wider range of options for expressing algorithms, and we simplify the story of how algorithms are…
So far, evidence is leaning toward latter view where physics imposes hard constraints on how we build our CPU's, etc for max performance. Same with software where certain things keep showing up (eg caching) due to mechanical constraints. Best result would seem to be a combo of abstract models for mathematical analysis and high-level languages that easily map to both those and the machines. Of course, many people have…
Re: Vigorous Public Debates in Academic Computer Science
#37One debate that I thought would be mentioned is "Goto statement considered harmful", "'GOTO Considered Harmful' Considered Harmful.", and "GOTO Considered Harmful" Considered Harmful' Considered Harmful?" I think it's somewhat disappointing that a lot of CS education always mentions Dijkstra's original argument, but not the other side. The latter two can be found here: http://web.archive.org/web/20090320002214/http:/…
Re: Vigorous Public Debates in Academic Computer Science
#38Earlier quoted context omitted.
So far, evidence is leaning toward latter view where physics imposes hard constraints on how we build our CPU's, etc for max performance. Same with software where certain things keep showing up (eg caching) due to mechanical constraints. Best result would seem to be a combo of abstract models for mathematical analysis and high-level languages that easily map to both those and the machines. Of course, many people have…
Lamport also advocates abstract models and high-level specification, but in program logics (based on abstract state machines) rather than in programming languages.
Langsec is a notable exception where Chomsky's hierarchy paid off big time. The notations and implementations still more consistent with Lamport, though. So, semi-exception.