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.
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?
Sounds like a typical computer science professor. Mine usually couldn't use a computer at all. And yes, mine were generally very cruel. Giving examples that months later they figure out were wrong, making us code with pen and pencil, teaching fake assembly languages and fake operating systems.
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.
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.
An Eye for an Eye will make the whole world blind - Gandhi
There's nothing exceptionally wrong with Java as a starting language, though I may be biased since that's what we had. In any case, my uni has now switched to Python, which is probably even better.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
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.
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.
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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
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.
Finally! A year of moderation! Ready for 2019?
you serious?
to me, system.out.println looks way more reasonable than this "cout << endl" thing.
factor 966971: 966971
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.
Turning? TurNing?!
Woe be to us, for all is certainly lost.
I think the problem is the false assumptions and analogies that get introduced by these lines of thinking. If a network is "this guy talking to that guy", your thinking will be constrained by what you know about human conversation. If there's a problem, someone can talk louder, slower, etc. and the analogy holds. But if the solution involves something that has no equivalent in the day-to-day world, how are you going to conceptualize it?
My pet peeve, that descends from this same idea, is from the teaching of object orientation. A car is a type of vehicle; a truck is a type of vehicle; they both have wheels; maybe the number of wheels is different; maybe each has a different turning radius or procedure for backing up.
Great, now you understand inheritance, polymorphism, member functions, etc. However, in practice, you use object orientation to avoid zillions of "if" statements, special case code, large blocks of almost-but-not-quite duplicated code.
In my experience, someone who learned OO by simple analogies is likely to be locked into thinking "I have to write every program by making a tree of classes like with the cars and trucks". Rather than "there are different ways to structure the code, and a good OO way will get rid of a lot of branching, magic numbers, and redundant code".
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.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
"I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself 'Dijkstra would not have liked this', well, that would be enough immortality for me." - Edsger Wybe Dijkstra
A lot of software engineers like to work with new technologies, new paradigms, new code design patterns, new software development technologies and other forms of complexity. Quality Assurance rules by checklists and testing, only fixing symptoms. Every coder has it's own ideology what is correct code or the correct way to do it. Correctness proven by superficial subjective quality standards, beautiful crafted hacks included.
Edsger found ways to mathematically prove programs to be correct, requiring a very high level of math skills (the same level which is needed to prove the correctless a mathematical theory). This utopistic objective quality standard. Stuff for the real hard core developers who have plenty of time.
But most haven't the time. In the end time-to-market is key. Swift hackers remain the heroes of business who craft applications which get used in the real world.
However some pragmatical things I thank Edsger Wybe Dykstra for: invention of the stack, his low opinion about the GOTO statement; shortest path-algorithm, also known as Dijkstra's algorithm; Reverse Polish Notation and related Shunting yard algorithm; Banker's algorithm; the concept of operating system rings; and the semaphore construct for coordinating multiple processors and programs. His charismatic remarks about what we would typically consider software engineering are entertaining and humbling, examples:
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.
Microsoft is to software what Budweiser is to beer.
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.
FOX NEWS.com should be BANNED from television and internet. Have the Congress take it over and give us Truespeak.
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.
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.
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.
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.
I am TheRaven on Soylent News
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.
I piss off bigots.
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.
(I was only an egg, but then I cracked)
But I think his arguments are centered around a misunderstanding of terms. It's simple academic dishonesty to which he objects:
The society for a thought-free internet welcomes you.
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.
In Capitalist America, bank robs you!