Slashdot Mirror
Twenty Years of Dijkstra's Cruelty
WatersOfOblivion writes "Twenty years ago today, Edsger Dijkstra, the greatest computer scientist to never own a computer, hand wrote and distributed 'On the Cruelty of Really Teaching Computer Science' (PDF), discussing the then-current state of Computer Science education. Twenty years later, does what he said still hold true? I know it is not the case where I went to school, but have most schools corrected course and are now being necessarily cruel to their Computer Science students?" Bonus: Dijkstra's handwriting.
Dijkstra's Cruel Font link, so we at least get something recent(-ish) out of this article.
There's nothing exceptionally wrong with Java as a starting language
Yes, there is. It insulates the student from some concepts that are important and because it's so aggressively object orientated even the standard "Hello World" program requires quite a bit of glossing over by the teacher.
As a result, it tends to get waved away as "magic" or "this will be explained later" but there's so much waved away that the students get disconnected. For instance, to simply output a line to a command line in Java you're looking at
System.out.println("output");
whereas with c++ (for instance) you have
cout << "output" << endl;
As someone who's teaching this stuff, the second is easier to explain in detail and doesn't rely on saying "don't worry what System.out is".
The other prime example when teaching object orientation is garbage collecting. Students who learn in Java are significantly more difficult to teach about dynamic memory and the necessity of cleaning up after themselves than those who've learned in other languages that don't abstract this away. It's much easier to switch from C/C++ to Java than the other way around.
The standard way of teaching basic programming is procedural, then functional, then object orientated then onwards. Using Java to teach in that cycle is nuts. How useful that cycle IS is another question, of course :)
Rational thought is the only true freedom
I think they should teach low level first, teach students assembly first and work up from their. They don't need to create anything fancy in assembly just make sure that they understand how a computer works and does things rather then the abstracted model that higher level languages give you.
I may agree with what you say, but I will defend to the death your right to face the consequences of saying it.
My old university dropped C and replaced it with Java for all CS courses apart from Operating Systems. I asked one of the professors why - he said many students complained that dealing with pointers was too hard, and that the rise of Java and Java programming jobs meant C was obsolete and pointless, that the issue of programming languages came up on prospective student visit days, and that in order to be "commercially attractive" to these potential students they had to switch. We even used to do assembly language programming in the first year - now, the replacement course teaches students how to use Eclipse for Java programming.
Several years later I was back tutoring, and I was very disappointed to find out that I had to explain pointers and pointer arithmetic to people who were almost at the end of their Computer Science degree, and who didn't understand why their code was crashing with "null references" when "Java was supposed to get rid of all that memory stuff!".
Dijkstra's comments were right on the mark, and fairly obvious to people outside of CS. They were only contentious within the field, for some odd reason.
The thing is, Computing Science should be approached in the same manner as most other science fields: A BSc in computing should be about theory, research, and pushing the state of the art. A modicum of programming is probably necessary to accomplish that, but programming should understood in the abstract--without the emphasis on 'this command, this language.' Learning to be a programmer (a) should be a division of computer engineering, or (b) probably not a degree at all. More like a one or two year college certificate.
Chemistry, Physics, Biology, Math, and so forth, are all degrees aimed at research and study, not commercial production. Why not computing?
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
I am very glad I never had him as a professor.
By the way, I am a physicist, and IMHO all of the best physicists develop a physical intuition about their physics, and that is certainly true with those who deal with quantum mechanics. Listen to the recorded lectures of Richard Feynman, for example.
As I read through his writings it brought me back to my time at Moravian College circa 1979. I just started taking CS classes and in that same year Dr Brown, Head of the CS Department pulled out all the IBM mainframe systems and installed a PDP 11/45. Gone were the COBOL courses replaced by c, RATFOR, PASCAL, Fortran et al. I loved it and hated it at the same time.
Like the presentation, Dr Brown taught us programming before we really saw the computer. His focus was not on Language, but on concept. As he so well put to us, once done with our intro class we could work anywhere in any language. I believed it then and found it to be a true statement. At the end of that intro class he took the last three weeks and taught sort algorithms. The catch was each sort was analyzed in a different language. I chuckle when I read posts of youngsters that say "I learned Java, or C++ in college". I learned Programming in college then went on to figure out what language suited my economic and intellectual needs.
Cruelty in Computer Science? I am grateful for that kind of cruelty to this day. Since college I have had to adjust my knowledge as times and needs change. I have had the pleasure of working with RPG, COBOL, Java, FORTRAN, and even the bastard child Visual Basic. Unlike some, I do not look down at any language for each has its benefits for the task. What I do dislike is working on code written by persons who thought that "Learn to Code Java in three Weeks" made them a programmer; that language X is the best and only language out there.
Dr. Dijkstra says "Universities should not be afraid to teach radical novelties". What things could be discovered if that concept was embraced again.
Life is a great ride, the vehicle doesn't matter
More than not being "great", he seems to be rather foolish...
1) His main premise is that "software engineering" cannot exist because software cannot be proved correct, only proved wrong. Well, I got news for ya - rocket engineering is the same way. So is electronics. So are bridges! Or do you think that having the SRB on the shuttle burn through the main tank was by design?
2) He goes further to say that foolish mortals (unlike himself) learn by analogy, and so can't handle the truth, etc. Then, hilariously, he goes on to say that the only true way to look at programming is as deriving a formula! Imagine that, a mathematician describing engineering as deriving a formula! No comfortable analogies here...
3) Then he talks about how computers are "symbol manipulators". OK, but that is not very useful - computers are really devices that get things done that we want done. Some people want photons in pretty patterns on their screens. Some people want the control surfaces of aircraft actuated in ways that save time/money/lives. But a computer/program is useless without the output mechanism.
Some of his conclusions are good - lines of code is an anti-metric. But in general, this paper was awful!
while (sig==sig) sig=!sig;
I've done nothing but C (not even C++) programming for the last decade in various full time and consulting positions.
Linux is all C and the job market for Linux kernel, driver and system developers has been pretty active for many years now. Using QNX and vxWorks is all C programming too (not counting the tiny bits of assembly you have to stick into your programs).
This is why I think it's important that people learn some assembly language once they are past the basic syntax of C. They don't have to become experts in the assembly, but being able to write (and debug!) a few basic programs in some assembly would be a good experience. Like a hello world(one that calls the system call, and one that calls a puts function), string reverse and maybe a linked list bubble sort. If you can get those 3 done in assembly after you've been exposed to C, it should make pointers (and arrays) a lot easier to understand.
I believe being able to debug is as important as being able to program.
“Common sense is not so common.” — Voltaire
Actually, Dijkstra spent a lot of time showing how to prove a program's correctness.
He did. In fact, he spent more time proving the program correct than it took to write, test, run, debug, and fix, the program, and then the proof still has to be checked for correctness. I learned the Dijkstra techniques for proving code. Even something as painfully simple as proving a loop invariant holds and would terminate was mind-numbingly difficult and tedious, and still fails to be correct in the presence of concurrency. Somehow the program proof advocates lost sight of Gödel's incompleteness theorems.
I'm not an advocate of Dijkstra's approach. However, does the Incompleteness Theorem really come into play here? I can't think of any useful algorithm for which I wouldn't be able to formally describe and verify the pre- and post-conditions. Can you think of any naturally-arising examples of algorithms for which undecideability might be an issue?
1. Computers are physical machines. The bounds of those machines are, in many cases, not fully understood, and in other cases, too complex for a single person to understand fully.
2. True-- but you're forgetting about the execution domain. Dijkstra points out that computers are simply "symbolic manipulators", and this is certainly true, but that does not make them general-purpose symbolic manipulators in the same way that a human is. A programmer must go to great lengths to ensure that, i.e., the number 1/10 or pi is preserved throughout the calculation chain, and doing so is computationally expensive. Sometimes prohibitively so. This is where engineering comes in, because if there's one thing engineers are really good at, it's deciding when something is "good enough" or not.
3. Sure, if you fully understand the phenomena. Are you telling me that your computational model fully accounts for turbulence?
What Dijkstra does not seem to understand is that engineering does not eschew mathematics. Engineers use the same theoretical knowledge that mathematicians and physicists do— they use the same analytical tools. Engineering is, rather, a superset of those analytical tools. It includes some new tools in order to deal with the complexity of certain tasks that are above the ability of most normal humans to solve. It is remarkably good at this.
Throwing out engineering because it will never solve the problem fully is like throwing the baby out with the bath water. Better solutions will emerge— functional programming, for instance, is very promising in many ways. I've read Dijkstra before, and I have great respect for him particularly because of his actual experience building large software systems. But this paper makes him sound like a bitter old man; maybe he didn't like the direction the field was moving.
Smalltalk (or, Self), Haskell, Lisp, Prolog and Erlang are all languages that fit into the 'learning these will make you a better programmer even if you never use them' category. I'd also through an assembly language (pretty much any one will do, although if you learn B5000 asm you will develop a passionate hatred for all modern architectures) in that pile.
I am TheRaven on Soylent News