Live data from Hacker News

Vigorous Public Debates in Academic Computer Science

blog.regehr.org

31–38 of 38 posts

Re: Vigorous Public Debates in Academic Computer Science

#31
post #28

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

[deleted]

Re: Vigorous Public Debates in Academic Computer Science

#32
post #28

Earlier 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?

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

Re: Vigorous Public Debates in Academic Computer Science

#33
post #8

While 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 produced such tools. We're going in what appears to be objectively correct direction. :)

Re: Vigorous Public Debates in Academic Computer Science

#34

Earlier 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…

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

Re: Vigorous Public Debates in Academic Computer Science

#35

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

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.

Re: Vigorous Public Debates in Academic Computer Science

#36
post #8

While 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…

Lamport also advocates abstract models and high-level specification, but in program logics (based on abstract state machines) rather than in programming languages.

Re: Vigorous Public Debates in Academic Computer Science

#37

One 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:/…

Personally, I thought that Knuth's Structured Programming with goto Statements was the most nuanced argument in this debate: http://web.archive.org/web/20130731202547/http://pplab.snu.a...

Re: Vigorous Public Debates in Academic Computer Science

#38
post #36

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

That's what I said but in different words. That's slso been where the payoff has beenin about any, automated activity on software. Generally some math notation that's easy to analyze or something close to CPU/memory models.

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.

Post reply on HN