Slashdot Log In
Twenty Years of Dijkstra's Cruelty
Posted by
timothy
on Tue Dec 02, 2008 09:46 AM
from the pleasant-legacy dept.
from the pleasant-legacy dept.
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.
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
The Text (Score:5, Informative)
While the handwriting is a novelty (and the PDF is actually small for a PDF), I question how long that server is going to last.
Also (and yes this is nitpicking), I must contest this:
Edsger Dijkstra, the greatest computer scientist to never own a computer
I submit for consideration Alan Turing [wikipedia.org] who may have designed the ACE and worked on the earliest computer (The Manchester Mark I [wikipedia.org]) although never really owned it or any other computer. I think a lot of people identify him as not only a hero of World War II but also the father of all computers.
Re:The Text (Score:4, Insightful)
I'd think Ada Lovelace would have a better claim there, given that not only did she never own a computer, they didn't even exist and there was at the time no such thing as a "program".
Parent
Re:The Text (Score:5, Funny)
Parent
Re:The Text (Score:5, Funny)
What do you think this is, wikipedia?[citation needed]
Parent
Re:The Text (Score:5, Insightful)
Woe be to us, for all is certainly lost.
Parent
Re:The Text (Score:5, Funny)
Parent
Re:The Text (Score:5, Insightful)
No.
(1) His argument is that to discuss "software engineering" is as silly as to discuss "algebra engineering" or "formula engineering" in math courses. A program is simply a formula to be executed - nothing more - says the Computer Science professor.
(2) Programs manipulate numbers. Mathematic formulae manipulate numbers. It's an entirely reasonable conclusion that he has reached that a program is merely a formula.
(3) Putting pretty pictures on screen or manipulating airplane surfaces (my specialty) is still just formula execution.
Parent
Re:The Text (Score:5, Interesting)
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.
Parent
Re:The Text (Score:5, Insightful)
I think you are missing his point, perhaps intentionally.
The vast majority of software is engineered - engineers are trying to get a specific outcome, they are not trying to calculate something.
Computer programs, he argues, are nothing more than long proofs. Each function you write is equivalent to a predicate in logical calculus, or a function in mathematics.
If you were only interested in outcome, you could write a program that multiplies two numbers together as a long series of "if" statements. But you'd most likely miss some possible values for inputs.
However, if you were interested in it being correct for all possible inputs, you would use the mathematical operation * or use a loop to calculate the correct answer.
I think that is the argument he is making and as a University professor, I tend to agree. I've seen some of my students test an array by using an if-statement for every single element of the array, where as a loop would have been infinitely more suitable.
Only one should be deemed correct. But if you adapt the "engineering" and "outcome" point of view, both are correct.
Parent
Re:The Truth (Score:5, Insightful)
I think this is a clear case of computer science and software engineering (without going into Dijkstra's assessment of that term) being different beasts.
Both the theoretical and immediately practical implementation of software are interesting and important, but they're studied in different ways by different people and trying to mash the two together tends to create more conflict than interdisciplinary synergy.
Parent
Re:The Text (Score:5, Insightful)
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
Actually, Dijkstra spent a lot of time showing how to prove a program's correctness. See his "A Discipline of Programming", for example.
Parent
Re:The Text (Score:5, Interesting)
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?
Parent
Re:The Text (Score:5, Funny)
My forte is made out of cushions from my mom's couch.
Parent
Mine was certainly cruel to us (Score:5, Funny)
They made us do mostly Java, even though a number of us could do C or C++.
Re:Mine was certainly cruel to us (Score:5, Interesting)
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!".
Parent
Re:Mine was certainly cruel to us (Score:5, Funny)
I love C. It's terse and really useful for optimising performance but it's really not a good teaching language.
C - all the power and flexibility of assembly language combined with the readability and maintainability of assembly language.
And I say that as someone who loves C.
Parent
Re:Mine was certainly cruel to us (Score:4, Insightful)
Honestly, it's most important to learn how to learn new languages than to learn any specific one. The specific language will change far more often than the concepts they represent.
Parent
Re:Mine was certainly cruel to us (Score:5, Informative)
You're right. Also Stroustrup had clearly pointed (in other argument lines) that C is not the better way to learn C++ (or OO in general):
BEGIN EXCERPT from http://www.research.att.com/~bs/new_learning.pdf [att.com] :
One conventional answer to the question ''Which subset of C++ should I learn first?'' is ''The C subset
of C++.'' In my considered opinion, that's not a good answer. The C-first approach leads to an early focus
on low-level details. It also obscures programming style and design issues by forces the student to face
many technical difficulties to express anything interesting.
Parent
Re:Mine was certainly cruel to us (Score:5, Insightful)
The C-first approach leads to an early focus on low-level details. It also obscures programming style and design issues by forces the student to face many technical difficulties to express anything interesting.
Expressing interesting things doesn't happen in a CS course, at least the ones where you're learning the language. It takes new CS students hours to implement the most simple linked list because it's not familiar to them. I learned low level first and I'm finding that it's the best way to teach my sister-in-law who's a beginning CS student. They're trying to teach object oriented features before they teach arrays or loops. Objects are constructs on top of the other programming concepts and should be taught as such. It was only after showing her how to use low-level features that she was able to start doing any semblance of OO programming.
People get so caught up trying to teach the "right" way to program that they don't teach how to program first, which is a mistake. Students need to learn the power and wonder of while, for, and regular functions before you can teach them the power of object oriented programming. Computer science is unfamiliar and strange, let students learn the simple things before throwing the advanced concepts at them.
I guess what I'm saying is that a good course would teach functional programming before teaching object oriented programming later in the same course.
Parent
Re:Mine was certainly cruel to us (Score:5, Insightful)
You're right. Also Stroustrup had clearly pointed (in other argument lines) that C is not the better way to learn C++ (or OO in general):
Somebody quoting Stroustrup on the topic of computer languages... seriously? C++ is like legalese -- it's impenetrable to read, full of unintended consequences, and even though it's spelled out in excruciating detail what it says is still open to interpretation.
Not only is C the first subset of C++ that programmers should learn, it is the only subset of C++ they should learn.
And I argue that C actually teaches people more about object-oriented that most other languages, because it teaches them in no uncertain terms why you should use objects. It's harder to realize why you don't just make fields public until you've seen global variables in a C program.
Then Java teaches you how to do OO where you are not allowed to 'cheat' by replacing methods at runtime, or calling methods that don't exist, etc. And JavaScript takes all that and gives you LISP power.
Parent
Re:Mine was certainly cruel to us (Score:5, Insightful)
There are lots of other reasons that I am too lazy to list here. Learning Java is not bad, but learning it as a first language does not make your life easy. A good introduction to programming course should cover half a dozen languages, as case studies, rather than attempting to use one to teach all of programming.
Parent
Cruel and couldn't use a computer (Score:5, Insightful)
I'm glad I left, cause I can actually now use a computer, unlike much of the coders I come across. If you like computers, don't go into computer science. That is for people who enjoy math and theory.
Re:Cruel and couldn't use a computer (Score:5, Insightful)
Why is fake assembly and fake OS cruel? It's computer science, not a vocational tech course. They've presumably tried to bypass the issues of real-world systems that distract you from learning the point. Once you've got the basic concepts, any OS and any language become approachable - why would you want to learn something specific that would be out-of-date in short measure? Seems rather myopic to me.
Parent
Re:Cruel and couldn't use a computer (Score:4, Insightful)
In a practical field where you can do real assembly and work on a real OS, you ask why doing fake make-work is cruel?
Theory is fine, but theory shouldn't trump practical application in a field where practical applications are everywhere.
Parent
Re:Cruel and couldn't use a computer (Score:5, Insightful)
Parent
Dijkstra couldn't use a computer?!? (Score:5, Insightful)
Boy do you need to go back to school. Edsger wrote more and better stuff in his lifetime than anyone here on Slashdot. Did you ever get directions from Google Maps or Mapquest? Thank Edsger -- his shortest path algorithm is what they all use, and by the way, he wrote that before you were born, most of you. You know the semaphores used in the multi-cpu Linux kernels? Yep, you owe Edsger for them, too. And programming languages like C, Pascal, etc.? He helped write the first Alogol compiler, the great-grand-daddy of them all, once again before most of you were born.
Just because he eschewed the run-break-fix approach so beloved of the folks who are spewing billions of lines of error-laden code into the world today, doesn't mean he hadn't forgotten more about writing code than most folks here have ever learned. And yes, he advocated developing code formally, and he liked to do it with pen and paper.
So learn about who you're making snide comments about, and show some respect. When people are still using any algorithm you came up with 30 years from now, you will have the right to say something about Edsger Dijkstra.
Parent
I have a lot of respect for him, but... (Score:5, Insightful)
The fact is that the world needs a hell of a lot of running code in a hurry. Millions of lines of it. We don't have the luxury of treating a realtime airline-pricing-optimization manager as a lovely formal system that we can write out in pencil. We have to get it up and running, then fix bugs and add features as time permits, because of a phenomenon that Dijkstra doesn't take into account: IT'S NEEDED *NOW*.
I also think he's being unfair by suggesting that modern educational institutions are anything like as hidebound as medieval ones. First, medieval universities were not intended for inquiry in the first place; they were intended to prepare young men for the priesthood -- i.e. to teach them doctrine, which was not subject to inquiry. No institution except maybe a seminary is as restrictive as that these days. Second, it doesn't seem to have occurred to him that learning by analogy is how people learn *effectively.* He may decry teaching children about arithmetic by using apples because it's not a formal system, but a five-year-old doesn't have enough knowledge to know what a formal system IS. Starting a five-year-old with Principia Mathematica is just pointless. And your basic coding grunt who wants to build websites doesn't need to be taught JavaScript as a formal system either.
Parent
Cruel to be kind (Score:5, Insightful)
The aim of a really good degree (as opposed to a lecture driven box ticking one) is to be cruel, you want to feel that your head is going to explode and that your subject really is an absolute bitch.
Then you graduate and find out the real world is easier than the theory.
Cruelty is important in a good education to make you achieve in the real world. An easy flow through degree gets you the cert but gives you unrealistic expectation of how hard the real world can be.
Personally my degree was a mind bending bitch of mumbling lecturers and impossible (literally in some cases) questions that covered everything from quantum mechanics "basics" and abstract computing theory through to how to dope a transistor.
It was cruel, it was unusual... it was great.
Handwriting? How about a Font! (Score:5, Interesting)
Dijkstra's Cruel Font link [tinyurl.com], so we at least get something recent(-ish) out of this article.
Do you really need that CS degree? It depends.... (Score:5, Insightful)
I'm grateful that I have a computer science degree, it has enabled me to have a deeper understanding of all the things I administer on a day to day basis. It is nice to know how spanning-tree actually works on my switches, and how databases actually use data structures to store and retrieve data.
I'm not designing and building these systems, I'm installing, using, and maintaining these systems. Do I need a CS degree to do this? Hardly.
If you like installing and maintaining computer systems, but hate math and theory - don't go for a CS degree. You will be better served by doing your own research/training, getting some certs (RH, MS, Oracle, Cisco...etc) and if you are so inclined, maybe a 2/4 year IT Management degree.
If you want to build the products that people install and use (software more complicated than a web page or login script, hardware, firmware for embedded systems...etc) you will need to endure the math and theory that a CS degree requires (and possibly an Electrical Engineering/Computer Engineering minor as well).
-ted
Back to the future (Score:5, Interesting)
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.
False dichotomy (Score:5, Insightful)
Most of y'all are presenting a false dichotomy. It's not "Either learn abstract formalism OR learn practical languages." You can do both, you know.
I have met too many people who think that, because they can write some tangled, fucked-up C++, they are software engineers. Never mind the fact that they couldn't learn LISP, Objective-C, Java, or any number of other useful languages, as they don't know the first thing about actual computing.
Teaching Java or C++ doesn't matter. Sure, you need classes on practical application of your knowledge. But if you ignore what Dijkstra says here, you're going to end up with a bunch of code monkeys who have to test every element of the set, rather than test the rules of the set.
In my experience, those who started off learning theory, then learned how to apply that theory in practical situations, are far better programmers than those who are taught "practical" languages.
There's some very good advice in that paper. Calling him "out of touch" is a bit shortsighted.
I can relate... (Score:5, Insightful)
But I think his arguments are centered around a misunderstanding of terms. It's simple academic dishonesty to which he objects:
Re:Hmmm... (Score:4, Insightful)
I agree that teachers disconnected from reality are bad, but the alternative is even worse. Look at what too much bitching got us: they teach JAVA as the primary programming language in universities nowadays! How sadistically cruel is that?
Parent
Re:Hmmm... (Score:5, Insightful)
Parent
Re:Hmmm... (Score:5, Interesting)
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 :)
Parent
Re:Hmmm... (Score:5, Insightful)
you serious?
to me, system.out.println looks way more reasonable than this "cout << endl" thing.
Parent
Re:Hmmm... (Score:5, Insightful)
I find it ironic that, to establish your argument that Java hides implementation details, you used a C++ example employing operator overloading such that the mere existence of functions is utterly concealed.
Parent
Re:Hmmm... (Score:4, Interesting)
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.
Parent
Re:Hmmm... (Score:5, Funny)
Ofcourse I can write a line of code!
Behold, in al its glory:
printf("hello world");
Parent
Re:Hmmm... (Score:5, Funny)
cat > hello.c
printf("hello world");
^D
gcc hello.c
hello.c:1: error: expected declaration specifiers or '...' before string constant
hello.c:1: warning: data definition has no type or storage class
hello.c:1: warning: conflicting types for built-in function 'printf'
Parent
Re:Hmmm... (Score:5, Informative)
cat > hello.pl
printf("hello world\n");
^D
perl hello.pl
hello world
Parent
Professionals should know their tools (Score:5, Insightful)
I agree with that, but it isn't only in CS courses that programming should be taught.
The problem I see in current engineering and sciences courses is that they don't teach numerical analysis. Engineers and scientists today try to do everything in matlab or excel, except for those that do postgraduate courses, who often try to do things in fortran.
Programming languages are tools that anyone involved with advanced uses of computers should learn to use. If you are a professional you should know how to use professional tools.
Parent
Re:Professionals should know their tools (Score:5, Insightful)
I don't think you can lay the blame for students knowing less on the department that they attend.
Mine taught a good mix of coding and theory, but we still had morons who didn't do enough coding to actually learn their craft well, and people who learned the coding but didn't learn enough theory to get decent course grades.
The point is, while at university studying computer science or any other subject it is your own responsibility to teach yourself around the subjects you are introduced to in the classroom.
I was taught using Java and Delphi, and yet finished my degree as a pretty competent C coder, in spite of never having attended a class on that language.
I also studied a great deal more around the subjects then many of my peers. Those who did the same as me tended to do well on graduation, I went on to more years of poverty as a Ph.D student myself.
Parent
Re:Professionals should know their tools (Score:5, Funny)
Our school had 3 separate Java classes, 3 separate C classes, and 3 separate C++ classes: all in 3 different departments.
Silly. This can't be true. Everyone knows that there are no classes in C.
Parent
Re:Hmmm... (Score:5, Insightful)
I'd have to say in recruiting software engineers I have much more of a problem with theory-light code monkeys than I do with non-coders that are well-versed in CS theory. With the former you wind up with people who can't leave whatever language they're most familiar with and don't really understand why what they're doing works (cargo cult programming). It's easier to teach good coding practices in the field than it is CS theory.
My technical interviews aren't full of riddles or obscure CS theory questions, but I ask a series of pointed questions to see if the candidate has a good familiarity with the various language families (not just particular languages), common data structures (they should at least have encountered them, even if they need to look them up to implement them), and can talk in terms of pseudocode and algorithms instead of just library functions and language idiom. Language experience is a plus, but definitely not required.
Parent
Re:Hmmm... (Score:5, Insightful)
i.e. CS programs producing students who know loads and loads of theory and can't write a damn line of actual code.
That's because CS programs are misnamed. Most coding should be done by engineers, not scientists. A Master in Physics doesn't necessarily qualify you to build bridges either.
Parent
Re:Hmmm... (Score:5, Interesting)
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?
Parent
Re:engineering (Score:5, Insightful)
I don't know what you think FrontPage has to do with anything. Perhaps you're just trolling?
Software engineers should understand use case analys, user interface design, project management and finance, and many other important subjects "computer science" curricula ignore while beating students over the head with details theory. Understanding issues of scalability is good (though often actual testing is used in the engineering world for practical reasons), but we don't need four years of that while ignoring more important topics.
I'm not saying exhaustive study of the mathematical theory of computation is bad. I'm saying students are badly served at most universities by focusing on that at the expense of other topics.
Parent
Re:Dijkstra is the typical head-up-arse CS crack (Score:5, Funny)
You have been trolled (by Dijkstra).
Parent