Talk:On the Cruelty of Really Teaching Computer Science

Authorship

As requested and as an actual participant in the 1990 debate On the Cruelty (http://catless.ncl.ac.uk/Risks/11.86.html#subj1) I have expanded this stub. --Edward G. Nilges

In case no one has thanked you, let me: it was an interesting read. Have you considered editing more articles? Wikipedia could use people like you. --maru 00:22, 6 May 2005 (UTC)

I appreciated the material; however, it felt very editorial in tone and more like a "review" of Dijkstra's remarks than encyclopedic content. Does anyone want to undertake a rewrite of the current content? --Calebbell 19:39, 27 October 2005 (UTC)

This article needs rewriting remove the gobbledegook and put whats left into plain words82.38.97.206 09:11, 13 January 2006 (UTC)mikeL

Women

What's with all the irrelevant references to women? Was this an actual part of the original debate, or is it just editorialising on the part of the writer? --221.249.13.34 04:54, 8 Nov 2004 (UTC)

Women...can't live with 'em, can't shoot 'em, huh?

The references are not irrevelant because the objections to Dijkstra's call for a "cruel" emphasis on symbolic manipulation as aired in CACM in 1990 drew fire primarily from women entrants to computer science: please check comp.risks posts and other sources from 1990 on this matter. It drew little objection from other quarters.

I was interviewed for a planned film on women and computing based on my contribution to the debate, which was that women were being done no favor by any de-emphasis on symbolic manipulation.

The issue centered on women and computing and was one in which Dijkstra (whose subsequently aired views on globalization were quite progressive) was re-presented as reactionary because of the paradoxes of identity politics.

Women's experience in computing was foregrounded in the debate. But because Dijkstra lost the debate, CS programs aren't honest about the intellectual demands of CS, which are discovered in a retail fashion, one at a time, by CS majors (how do you debug a C program? change your major).

CS is now taught like calculus in which foundational problems which affect the teaching are brushed aside in macho pragmatic fashion, and the emphasis is on the use of fashionable and Politically Correct platforms like Linux.

To be part of the action and to have a lively and readable style isn't necessarily "editorializing" although of course it might be. NPOV has more to do with purity of heart in Kant's sense than LCD. Which is of course a meta-POV.

Signed, --210.21.221.178 02:14, 9 Nov 2004 (UTC) (four tildes, how about that: how gnomic) Edward G. Nilges

Fair 'nuff. Thanks for the response. --221.249.13.34 02:10, 25 Nov 2004 (UTC)

Well, I'm removing the "Gender Issues" section because what's stated in it is untrue. The 1990 discussion in the Communications of the ACM contains no such subject. This might have taken place elsewhere, but it most certainly didn't take place in the CotACM. Not in 1990 and not at any other time either. It's not false that "The paper triggered a discussion in 1990 in the Communications of the ACM " (that's true) but everything following "because" is not represented in that discussion. So for the record here's what's getting removed:

=== Gender issues ===

The paper triggered a discussion in 1990 in the Communications of the ACM because two computer science educators felt that Dijkstra’s views were exclusionary of women, who, it was claimed, would be more interested in group projects and the use of software products, in place of the exacting demand, by Dijkstra, for formal, mathematical thought by individuals, who would then defend their programs and derivations to like-minded peers.

--198.49.180.40 (talk) 22:35, 9 October 2008 (UTC)

Computer Science v. Mathematics & Ivory Towers

Computer programs are written primarily for real-world purposes. Mathematical proof or freedom from bugs is far down on the list of priorities, and rightly so.

Microsoft does not need formal proof to market and sell a product. Producing a formal proof would be a massive effort, costing more money that could be recovered from the value-added the proof might produce.

Even if they wanted to, no sufficiently-rigorous definitions are ever produced for large programs to drive such a formal proof.

Formal proof of correctness is the essence of Ivory Tower.

Only someone who has never worked overtime against a ship date, and never dealt with fuzzy requirements, and never fended off a customer so eager for a product they would take a version known to be buggy, would fail to see, or de-emphasize, the real-world counterpoints to thus exalting formal proof. = unkown = --Williamv1138

In 50 years nothing will be left of Microsoft's current code, but everything of the proved algorithms. That's why CS needs structure and rigor: not only for today, where a quick hack will mostly do the job, but to build strong foundations for tomorrow. --alex =

Don't count on it, have you heard about backward compatibility? :-) --Ejrrjs | What? 21:25, 10 Jun 2005 (UTC)

In any case, where are those proofs stored to be checked when we need'em?

Nice, permament, world-readable/-writable, open format, dead wood? --maru 23:21, 10 Jun 2005 (UTC)

Not: how?, but: where? (Seriously) --Ejrrjs | What? 08:08, 11 Jun 2005 (UTC)

Seriously: are you playing dumb here? The same place books have always been kept- libraries, universities etc. And they can easily be ASCII-ized and kept in that fairly future-proof format if need be. --maru 15:23, 11 Jun 2005 (UTC)

Calm down, and measure your words carefully before writing. And do not sell snake oil solutions that you are unable to locate. It seems that you have (not) the slightest idea on how to write a functioning program, how to test it and how to deploy it, either as a commercial product or as an internal development for an organization. In real life, it seems that only highly critical DOD and real time systems will be able to afford the cost of formal verification, so your dreams won't became true. Now, go back to your ivory tower, and close the door behind you. Ejrrjs | What? 17:19, 11 Jun 2005 (UTC)

I don't follow your train of thought there. Anyhow, I think the point being made is that formal proof is an excellent tool for writing critical, reusable algorithms and really proving that they work, indeed like the famous Dijkstra algorithm, and that this is reason enough to teach formal proofing. I think that we agree, however, that formal proof is too much work to be applied to large systems as a whole. Devnevyn 14:29, 3 September 2005 (UTC)

Sorry if I'm not explaining myself as clearly as I would like to. Anyway, I think we do agree. It is certainly valuable to study formal methods, certain critical apps (real time, security,..) may benefit from them, but I'll bet they'll never become mainstream engineering tools.Ejrrjs | What? 16:20, 3 September 2005 (UTC)

Formal methods were not developed for the everyday software developing workforce, but for the computing scientist, the one who'll be developing crucial results in the academic midst, results that will then be applied, albeit in a haphazard and careless way, by the software engineers in everyday life. Whenever you implement a known algorithm into a real life program, that algorithm was already proven correct by whoever concieved it, such as Dijkstra's Shortest Path, Kruskal's Minimum Spanning Tree, John von Neumann's MergeSort... Do I really have to continue? — Preceding unsigned comment added by 187.52.8.230 (talk) 22:04, 22 February 2012 (UTC)

I think the point that Microsoft would never be able to ship any software if it went about formally proving them is irrelevant here. Development in production environments may need no proof. But students must be taught so as to reason about systems in a formal abstract way, rather than a behavioural way based on test inputs. The key idea is that if some one were to ask you to write a proof for your program then it must be considered possible. Attempting to reason abstractly can give tremendous practical results otherwise impossible. Consider the 4 line parser combinator library in Haskell and compare it with the code complexity and the number of bugs in yacc. http://www.cs.nott.ac.uk/~gmh/pearl.pdf. The former is a result of attempting to reason about the parsing problem in an abstract way using mathematical constructs called Monads, while yacc is a product of software engineering. Thinking symbolically broadens the scope of problems we can attack. Consider the 3 line proof for the Sine Rule using Vectors and the reasonably complex one, without Vectors. The Simplex method wold never have been developed without concepts like Vector Spaces. But programming today encourages behavioural thinking using arrays,structs and now classes, but does not attempt to develop an algebra with its required operators and axioms. If students were taught how to develop a few algebras in their CS courses, they would develop into better programmers and we would have better computer systems. Inventingfacts 01:30, 15 December 2005 (UTC)

---

The position expressed in e.g. Kernighan and Plauger's The Elements of Programming Style has an interestingly equivocal relationship to Dijkstra's. It's far from academic and not concerned with proving the correctness of programs, but they shared Dijkstra's concern with structured programming somewhat before it became ubiquitous, and they have some sarcastic things to say about cleverness and "efficiency" ("One hopes that the increased efficiency of the program will help to compensate for giving everyone a 10% discount." "Presumably this means that it is vital to get the wrong answers quickly.") DanielCristofani 09:42, 17 December 2005 (UTC)

Major cleanup

I did a major rewrite to remove editorializing and make the flow sound more encyclopedia, rather than an essay written by a friend or colleague.

I moved some biographical text to Talk:Edsger Dijkstra, since it seemed more appropriate for that article, if it's going to be anywhere.

I was unable to resolve one issue. Consider the following quotes:

many students were beginning to ask in good faith why they (to use a common complaint) had to learn how to write a compiler when so many compilers had been written.

They asked, in good faith...why it was necessary to be so apparently arrogant as to appoint oneself to re-analyze the problem, “all the way down.”

Unfortunately, this fails to prepare many for the “cruelty” of writing, for example, a C compiler in C, and, the very act seems unnatural, and carrying coal to Newcastle in the problem formulation alone.

You certainly don't need to know the details of how a program is actually compiled and run in order to be able to model it mathematically and make formal statements about it. I'm not sure the debate over how much detail students should be taught is related to the debate over formal correctness. Was the compiler example or anything like it something Dijkstra used in his paper? If not, it might not be relevant to the topic.

At MIT, at least, computer science majors are taught everything from how the EM fields inside transitors give rise to their electrical properties, to how they are assembled into logic gates and chips, to how the kernel and compiler work, to high-level artificial intelligence techniques. The introductory CS class includes the construction of a Lisp interpreter in Lisp, which is indeed rather mind-warping and somewhat pointless except for its educational side-effects. (But why else would you be in college if not to learn? Wait...don't answer that.) I can't really evaluate the scope of the curriculum at other schools, though, and that only needs to be in the article if this is relevant to assessing the legacy of this paper.

-- Beland 01:42, 2 May 2006 (UTC)

Pedagogical legacy - Counterexamples

I removed "Not true about the University of Warsaw" because it wasn't referenced or explained. Also, I'm not certain that listing schools that follow Dijkstra is a good idea. If there are schools that follow Dijkstra, we can weaken the wording ("most schools don't...") and reference some curriculum/course explanation pages that use Dijkstra's methods. --JamesBrownJr (talk) 22:53, 7 August 2009 (UTC)

Ambiguous phrase needs disambiguation

From the article:

"Until the end of his life, Dijkstra maintained that the central challenges of computing hadn’t been met to his satisfaction, due to an insufficient emphasis on program correctness (though not obviating other requirements, such as maintainability and efficiency)."

The phrase "until the end of his life" is problematic: one might reasonably infer that Dijkstra changed his opinion at the end of his life, shortly before death.

I think this is probably not the intended case -- it's more likely, in my mind, that Dijkstra did not change his opinion -- in which case, the phrase should read "throughout his adult life," or words to that effect.

If you know the facts of the matter, please update the article as appropriate.

Karl gregory jones (talk) 17:57, 13 September 2012 (UTC)