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.
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 who may have designed the ACE and worked on the earliest computer (The Manchester Mark I) 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.
My work here is dung.
They made us do mostly Java, even though a number of us could do C or C++.
I'm a high-school student and I know that most people here can't even pronounce his name.
Wasn't Dijkstra the one who said "Computer Science is no more about computers than astronomy is about telescopes"? Great as he was, I'd say in the modern era he's part of the problem, i.e. CS programs producing students who know loads and loads of theory and can't write a damn line of actual code.
Regardless of the state of Computer Science, what most students studying the subject really are after is software engineering. The world doesn't need more people arguing over P=NP; it needs people who can build (and manage projects to build) software systems which solve real-world problems.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
When I took my C++ Data Structures course, our final was 36 pages long. We had to hand write our code answers. That was cruel. That was in the ol' year 2000.
No single raindrop believes it is to blame for the flood.
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
Edsger Dijkstra, the greatest computer scientist to never own a computer...
So, his Macintosh wasn't a computer?
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
...having to spell the guy's name. Out loud. In front of the whole class. While hung over. On a Monday morning.
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.
Alan Turing couldn't have owned a computer.
Dijkstra's Cruel Font link, so we at least get something recent(-ish) out of this article.
While there are a number of things this gentleman has correct, there are also a number of dreadful errors here. Two examples: he subscribes to the belief that the Middle Ages were "poor fools" and he denies that Arithmetic is the derivative of physical problems -- one apple and one apple can be written 1a + 1a = 2a.
http://www.allen-poole.com/
I am a Software Engineer and my cruelest subject was Electro Magnectics. (Shiver) I think I finally understood it, and then I found out there are left-hand materials too. (Shiver, Quiver)
"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."
Maybe in computer engineering they might but I learned mathematical analysis right off the bat and no it wasn't post doc. It's kind of hard for one to call themselves an engineer and not know that.
Shai Schticks:"You don't make peace with friends, you make peace with enemies"
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 study at the university of Eindhoven, where dijkstra was professor. He certainly left his mark on the curriculum here with constructing programs by proof by using hoare triples and much more.
A lot of the staff here see him as sort of a role model, with the same proofs, handwriting and abrasive personality.
But now the last year most of those subjects are being removed, or reworked to something more manageble. They where so disconnected from reality (proving horners scheme in so many ways gets old quick).
Dijkstra's quote "Computer Science is no more about computers than astronomy is about telescopes" is in my opinion just wrong. Astronomers need to use a telescope and understand its operation.
Dijkstra was a genius and made many contributions to Comp. Sci. But his suggestion that a program (really a program design) should be accompanied by a formal proof has problems at both ends of the development cycle: how do you prove that the formal specification is what the customer wanted, and how do you prove that the code actually implements the design?
I've seem automatic testing products that claim to do both, but in order to make them work you have to specify every variable and every line of code as the "requirements", then compare what the tool thinks the result should be to the output of the program. And yes, the vendor suggested that the business analysts write the formal requirements; you can imagine how well that worked.
"Right from the beginning, and all through the course, we stress that the programmer's task is not just to write down a program, but that his main task is to give a formal proof that the program he proposes meets the equally formal functional specification."
Where exactly do semi-formalized, poorly thought-out specifications handed to you half-written out on a napkin and constantly subject to change fit into the programmers task and Dijkstra's world?
The glaring hole in Dijkstra's argument is that most software is built to automate what used to be manual processes, and they therefor have to mimic a human-centric process... which is inherently illogical, inefficient and rife with nonsense.
In the world outside the ivory tower, programmers do not have the freedom to create completely logical, functionally complete programs that can be reduced to a mathematical proof.
Next time your boss comes to you with an project to write an application, show him this paper and explain that what he's asking for is "medieval thinking" and see if you can then explain to him why you should keep your job if you don't want to do it.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
based on Electrical Science, or Mechanical Science, are there?
So, why, then, are we forcing kids to take Computer Science, when what most of them really want is Software Engineering?
The only answer that I can come up with is that the people who come up with curricula are failed software engineers, and are trying to bring everyone else down with them. I interview kids with degrees that can't tell me what a heap is, or why I'd want to use a hashtable rather than a binary search tree, or vice-versa. Now, I know they had to learn that stuff, first year, but they haven't had to use any of it, since.
The ones who retained their first-year stuff often don't have the other engineering basics down, patterns like IOC, class factories, singletons, etc., are just vague ideas to them. Ask them to explain why you would use a class factory, instead of just calling new, sometime. That will bring an entertaining answer, 90% of the time.
Computer science doesn't concentrate on engineering skills, or it didn't when I was in school (UTexas in the 90's). I had to learn how to optimize various languages on my own. I had to learn various languages on my own. I have no need of calculus.
Now, I suppose there are jobs I could get, if I'd finished my degree, that require a lot of calculus. Physics engine designer, etc. There are plenty that don't, and don't require me to be able to design an operating system, either. Those things are niche specialties. What I know for sure is that 90% of the valuable information in my head was learned on my own time, or on the job, and that when I went to school, no classes covered much of this information.
Kids with degrees are notoriously goofy with multithreading (from our experience interviewing them), no longer a niche discipline, with multiple core machines commonplace today.
Ultimately, I find that a degree in CS is little to no positive indication of aptitude in Software Engineering. That's truly sad, and just plain dumb, besides. We're in trillions of dollars of debt. It's affecting our bottom line!
All I have to do is read one paper like this to be reminded why I stayed out of academia. Ah the smugness, the hypocrisy, the great irony. A "radical novelty" this essay is not.
There are plenty of truths out there yet to be discovered. Unfortunately most academics lack the self-confidence to go looking for them and instead find clever new ways to twist ideas around.
The thing that confuses me the most about this paper is his hatred for using anthropomorphic metaphors to describe the functioning of a program. It confuses me partly because his examples of why it's bad don't seem to actually address his complaint, or anything like it. But also, because the more I think about it, they seem to fit very well.
Program components may not be living things, but they do run autonomously. They perform actions, frequently without any input from me. They seem to do things and interact with other components on their own - why not describe it as such? There's also the fact that he doesn't give any alternate way of describing what's going on inside a program.
There are some good quotes atributed to him, but one particular one that goes to show how very wrong even experts can be:
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
In my experience this is utter arrogant rubbish. Not being able to teach good programming to people who know Basic only stems from the inability of people like Dijkstra to teach. One of the reasons I usually stear clear of all to academic IT enviroments and programming languages. Like Ruby or Java.
We suffer more in our imagination than in reality. - Seneca
I don't think I really understand what Dijkstra is getting at here. Can someone explain it to me with a car analogy?
I've taken CS classes at a few different Universities and Tech Colleges.
At the Unis I learned theoretical stuff that as a business application developer I will never use. I will never bill my employer/consult to build a new compiler from scratch. Knowing the intricacies of how compilers work has never contributed significantly to my ability to debug a code problem. That said, they did a fair job of what they were trying to do: spit out scientists who could further the field of computer science.
At the Tech schools I saw a ton of technologies. SQL, SQLServer, C++, C#/VB.Net, Java, HTML, CSS, Javascript, Access, etc... tons of hands on lab time. And walking out of a tech school program I felt they did a great job doing exactly what they were trying to do: spit out working class programmers who could hit the ground running on day 1 in a wide variety of entry level contractor jobs.
Neither option is perfect. Going to a University you'll miss out on the actual practical coding, so while you might be able to pointer math in your head, you'll be way behind the curve in application development. Going to a tech college, you'll have a great framework to start from, but you'll have none of the in-depth or more advanced technical knowledge that someone with a university degree will have.
In both cases I found the knowledge transfer on application design to be completely lacking. Limited exposure to design patterns. No coverage of data abstraction or n-tier designs. Course work on customer interactions, requirements gathering, documentation, and project management were completely lacking (although the tech colleges did a fair bit of PM and Business focus in their Bachelor's program).
When I'm looking at college grad resumes, from a programmer's perspective I want to know that they can:
1) Code in 2 languages (preferably with different fundamentals)
2) Understand some amount of design theory
3) Manage their time
4) Interact well with users and coworkers
And for the love of all things binary, if they try to answer the "Swap the values of A and B" with out creating a 3rd variable on the screening test, they get round filed. I don't care if an instructor showed them a neat trick with pointers, answer the question the right way and save the flaunting for personal projects.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
We wouldn't have actual computers, only theoretical ones.
Dijkstra's a genius, but, like almost anyone on the 99.999 percentile of the bell curve, is a mere crank when discussing anything outside his core area of expertise.
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.
However, I can't get behind the man's call to teach without compiling and running programs. Well, to be fair, I'd have no problems teaching a freshman college course that way, but I'm teaching teenagers. I want the students to be able to unleash what they have wrought (or at least see that they've created a program that works). That's the bait that hooks them deeper into the coolness that is computer science or software engineering or programming or pattern engineering or thinkyness or whatever you care to call it.
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
That is spot on. It is the difference between an electrical engineer and an electrician. They don't do the same things and getting an EE to wire your house is as stupid as getting an electrician to design a CPU. Or you don't go to the engineer at GM who designed the engine of the car to change your oil (although given the state of Detroit that might change).
There is a difference between a CS degree and an IT or Software Engineering some other more hands-on degree. Yes, a CS or Comp Eng degree should have coding, that is a must because you need to implement a stack or queue or linked list to really understand it. Ditto for LISP or Prolog in AI or knowing a bit of C if you are into OS design (e.g. for Unix/Linux, so you can understand it). But the focus is on theory so that you can code efficiently (or tell the IT people, look, your coding is good, but the design is O(n^2) and you could code it so that it is O(n) or whatever). Or to tell them P NP or whatever.
I was just starting grad school at UCSD in CS when he wrote that paper and there are two separate fields here just like a builder vs an architect or plenty of other examples. One is not better than the other, just different with a different focus and just depends on what the person is interested in and wants to be skilled at. It is not widely understood though. When people find out I was a CS person, I get, "Oh, can you fix Windows for me?"
As Dijkstra put it, "...because persons exist and act in time..." And his claim was that using 'operational reasoning' was a 'waste of mental effort', and he used his domino problem to illustrate a problem where 'operational reasoning' is particularly ill-suited.
However, not all problems are like that, and humans have - in essence - hardware-accelerated modules for performing time-and-agent-based operational reasoning. Dijkstra was half-right: "refusal to exploit this power of down-to-earth mathematics amounts to intellectual and technological suicide", but also half-wrong - not all problems succumb so directly and easily to "down-to-earth mathematics", and not using the human talent for 'operational reasoning' is also "intellectual and technological suicide".
PHEM - party like it's 1997-2003!
Tinyurl? That isn't the shortest path to the link, y'know.
Dijkstra mocks concerns about the lack of "programming tools". I think he is wrong on this one. Refactoring can be thought of as a programming tool, and it is a very useful one.
\u262D = \u5350
I think both approaches (top-down and bottom-up) make sense. You learn C very fast if you can think of it as a high-level assembler. And learning assembler teaches you a lot about what computers are all about and what they can and cannot do.
But learning algoriths on C or other low-level, manage-your-own-memory languages is unnecessarily painful and error-prone. The algorithm exists independently of a specific language incarnation. Learn the algorithms in a language that makes it easy to concentrate on the problem and not get lost in a thousand small implementation details.
You reach enlightenment when you can bridge the gap from very low level to the highest levels. But it is folly to try to do everything at once.
Can someone tell me on which page he stops the senseless rambling and gets to the point? I can't imagine having this guy as a professor. He loves to hear himself talk too much.
cout doesn't have any meaning if you don't scope-qualify it any more than 'out' does. So you have 14 vs 13 non-output characters. Not exactly game-changing.
The P=NP problem is just the sort of educational fluff that makes students think they know theory when actually they do not. The students then believe that theory does not help them write programs (although it may help then analyze existing programs). Abandoning theory, they glibly program using the one and only strategy "software engineering" affords them: guess and check. First, they guess: make a mental image of what the computer ought to be doing, and program it in. Next, they check: run the program a few times (if that) and see what happens. No wonder program errors are considered omnipresent and inevitable.
To make matters worse, most introductory theory courses leave students with the distinct impression that program correctness is to a certain extent unknowable. While the P=NP problem is harmless (if lightweight) the halting problem and the accompanying Rice's Theorem are downright insidious. Dijkstra is right that programmers don't want to take responsibility for their own errors, and Rice's Theorem allows them to use the "unknowability" of correctness as justification for making mistakes. (The correctness proofs that are constructed in algorithms classes ironically reinforce this notion by cementing the idea that correctness is something you worry about after the fact.)
It doesn't take a prophet to see the emerging regime of certified programs. Once that comes about, all mission-critical software will be made using formal proof techniques, since this has shown to be the only way to be 100% sure that no errors exist. Then and only then will we as programmers really be able to claim to write programs that "solve real-world problems" rather than programs that sometimes behave correctly and sometimes cause a catastrophe. You may not like it, and it may go against your ingrained intuition, but it will happen and you'd better be ready for it.
I'm afraid I'll have to differ.
There is nothing more fascinating than learning how computers really work. And this background is essential when designing algorithms and memory structures that must be efficient. It is merely a question of teaching this in an interesting way, and of relating it to real-world problems, such as "why is this pretty reasonable-looking high level language code so fucking slow?"
Fantastic article. I especially like this part:
(1) The business community, having been sold to the idea that computers would make their lives easier, is mentally unprepared to accept that they only solve the easier problems at the price of creating much harder ones.
So true. I deal with this every day. Despite the high tech wizardry around us, business still runs pretty much the same. Just, the management is all too happy to throw its problems at someone else. I can't remember how many times in the past that I've had a client, boss, or manager ask me something that is impossible and tell me "fix it" or "make it work".
...have most schools corrected course and are now being necessarily cruel to their Computer Science students?
Buddy, we have 6 assignments, 2 quizes and an industry project presentation this due week.
You tell me!
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'
Babbage's Difference Engine was a calculator, not a computer. However, I do take slight issue. Anyone who has read about what Turing made the Manchester Mark 1 actually DO, apart from being suitably awed, would have to admit that while notionally it belonged to Manchester U, Turing definitely pwned it.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
"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.
Second semester freshman course is mostly about constructing machine-checkable proofs about programs. http://www.ccs.neu.edu/course/csu290/syllabus.html
He's saying that computers represent combustion driven vehicles, as compared to sweat and bones driven vehicles, and that even though the wheels and the body may look similar, the purpose the same, we cannot faithfully still call a car a carriage.
This was a great way to start my day. So seldom do I thank you, slashdot...
I think that some schools produce people who cannot write code -- especially this day and age -- is that those people really cannot conceptualize and abstract well enough to write code.
Dijikstra's point, and I agree with, that Computer Engineering has deteriorated in to a methodology of teaching people who cannot program - how to program.
Yes, it is true, that not everebody who can do well in mathematics can be a good programmer. That has to do with their personality and probably lack of motivation to understand and
conceptualize problems that were created by humans and not natural systems (like CRMs).
However, the chances that a person who does not have brain for math -- can be a good programmer, I think are nil (or null). Regardless of how much
education they get.
The untold truth is -- that because pay is good (compared to many other fields) -- there is a huge number of people who enter the field of computer science that should not be there.
The ones who graduated, entered the workforce
and figured out that they cannot really do it -- become either Managers or QA specialists. Both are horrible outcomes for the industry.
If you look at this -- we have driven our customers to expect patches, updated, bug fixes etc as a 'natural course' of operation. I personally do not think this should be acceptable.
If the requirements would be to create functional software (and not support the functions that do not work or work partially) -- then the type of people who would be required to produce such software would be very different than 80% of the todays programmers (no matter what country they are from by the way... I have done 4 month of interviews in Moscow, Russia of candidates
from prestigious universities -- and some did not know that an array had to be sorted before doing binary search -- but they knew Actors and Action in OO design and why XML is so great...).
Ok, I get that Dijkstra was a profound mathematician type. But honestly, with regard to computer science, he just comes off as a fuddy-duddy luddite. I know a few scholars who refuse to use word processing applications to write their papers (one tenured researcher at my work, a phd mathematician well past his prime will only use his old IBM Selectric), regardless of how well they know their productivity could be increased. And I don't want to hear any aesthetic arguments. If I were an employer today I might find such behavior 'quaint', but of no use on my payroll. None. In my opinion he just comes off as an intelligent quack.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
I must say that I agree very much with many of the points he's made in this paper. Anthropomorphizing concepts and excessive use of analogy is bad for teaching programming and it's bad for teaching many other concepts.
In terms of programming, one thing I absolutely hate are "real life analogies." Take the "Head First" series of books. On one hand they're very good at diving into subjects and explaining the concepts in several different ways. On the other hand, all of their examples are so far removed from reality that they're meaningless outside of the context of high level discussion. "Bill and Ted want to order a pizza, but Bill wants a Chicago style pizza and Ted wants a New York style pizza. What they need is a Pizza Factory!" Huh? I mean, I get it, but completely outrageous analogies don't really help when you get into the process of actually writing code. If outrageous analogies did work, then naming would be a breeze....writing comments would be fun!
Another example of poor example is the familiar "let me teach you about Object Oriented Programming by considering a circle, a rectangle, and a square." Of course these three things are all "shapes", and invariably they all "draw()" themselves. You can replace this example with the tried and untrue animal (or dinosaur) example in which an array of animals or dinosaurs are all related and differentiated and all, of course, "bite()" or "move()". These examples are horrible because they ask more questions than they answer. That is, the concepts behind OOP are not so complex that they require high level analogy to explain -- as if the people who will be writing OOP programs are non-programmers. And when the brain starts to consider how these analogies apply to real-life situations, it wonders things like, "wait a minute, why would a circle draw itself? What does that even mean? On my screen? In a window? On some paper in my printer? Or does it just return some data structure containing points? What is the value of that?" and "ok, my dinosaur just "bit()", but what did it bite on? How can my cheetah "move()" without knowing about its environment?"
In the end, the concept is understood but the actual implementation -- how these concepts can actually help us in the completely abstract unreality of a computer program -- is missing. What's most disturbing is when a text book will start with one of these corny high-level examples and then actually IMPLEMENT the example verbatim. That is, they'll have crazy polymorphic tyranosauruses and cheetahs and ducks all biting on shit in a completely meaningless exercise that wouldn't even apply to video game design.
In the non-computing world, poor use of analogy and anthropomorphizing concepts has an even greater impact on our reality. Consider the following statements: "buffalo travel in herds because there is safety in numbers." "Lions have eyes in the front of their heads to focus on their prey, and zebras have eyes on the sides of their heads so that they can watch out for lions."
Both of these statements would be considered basically true, however they are completely false. Buffalo travel in herds because that's what they do. Lions and zebras have eyes where they have eyes because that's where their eyes are. They had no choice in the matter. Their evolution was not one of decision making, but of beneficial mutations and lots and lots of death over thousands of generations. Explaining this as though some sort of strategy were involved only complicates matters and makes it more difficult to grasp the scope of time required or appreciate the concept of genetic mutation as something that has nothing to do with the Incredible Hulk.
I don't think I have to explain why injecting decision making into evolution is a dumb and dangerous thing to do, and does not help to further our knowledge of the subject but in fact just the opposite. Ok, I will explain it: intelligent design.
Towards the end of the essay, an introductory course is described where the student, as programmer, is required to build a formal mathematical definition of his program and prove that his program conforms to the definition.
At The Ohio State University, we teach precisely this in the form of the "Resolve" programming language. For every function and every block of code, one must provide both the procedural code and a set of logical constraints that describe the effects of the process. For instance, if a function's job is to reverse the order of items in a list, then the internals of the function are accompanied by a logical constraint that tracks the movement of items from one list to another and ensures that the operation is totally consistent at every step, in terms, for instance, that the two lists sum to a constant size that is the same size as the input, and that the concatenation of the lists in a particular way yields the original list. (I'm summarizing.)
An active area of research here is on automatic provers that take your code and your logical definitions and actually prove whether your code and defintions match or not.
I haven't read this essay before, and have only had time to skim part of it now, but Dijkstra's criticism of mathematicians has merit, IMHO. [I have an MS in Math, so I don't claim to be an expert.] It's been over 40 years since the introduction of nonstandard analysis (including hyperreals and later surreal numbers), but it's still not a mainstream topic. In fact, it boggles my mind why a professor or department would choose to teach their students "hard" analysis (Bartle or Royden) instead of "soft" analysis (Rudin) -- "soft" analysis uses topological results to arrive at key theorems faster, while "hard" uses Real Analysis as if it were the only option on the market. Not that there's anything wrong with using Rudin and Royden in tandem, but to ignore topological results altogether smacks of willful ignorance. To paraphrase Stephen King: do you expect brownie points for being ignorant of your own discipline?
The light on the horizon is the development of proof via programming, as covered by /. I'm sure there will be 50+ years of mathematicians screaming and kicking to avoid its introduction into the mainstream, but that will change the first time a computed proof that could not have been developed in one lifetime via the usual methods earns someone an Abel Prize. Until then, I suspect Dijkstra's point will still stand.
I find it absolutely amazing how the field of software engineering is filled with countless "code monkeys," and yet, none of those people ever participate here on Slashdot.
:)
This was not meant as a shot at the above poster. Just an observation
Do you (or anyone else) have recommendations for schools that do a good job at teaching software engineering? I work with HS students from time-to-time and it would be nice to have some place to recommend.
I went to a science/engineering school and got a good Computer Science education there. I agree that it would have been nice to have a couple more classes on software architecture, testing and planning, and that some of the CS classes like Automata (which I enjoyed) aren't useful for 99% of the students.
However, the problem I've found is that all the good schools teach computer science and the ones that claim to teach software engineering are usually no better trade schools that crank out people who know a few technologies but none of the principles behind them. I wouldn't give up a rigorous hands-on treatment of Data Structures, Algorithms, and Systems Architecture for the world, so I still end up recommending a good CS program over software engineering, even if it means suffering through a few unnecessary classes.
Mod parent up. The analogy of [physicist : engineeer :: computer scientist : software engineer ] captures exactly the distinction between theorist and practitioner that is conflated in our industry.
He could of summed up his paper by yelling Troll, Groupthink, and then Personally I welcome our Automatic Computer overlords.
You can tell he never owned a computer by the way he doesn't think programs need maintenance. He is confusing cause and effect. The environment the program "lives" in changes and "wears" it out therefore it needs maintenance.
"The stupid neither forgive nor forget; the naive forgive and forget; the wise forgive but do not forget." -Thomas Szasz
It's not perl if its not nearly completely unreadble :D
It is really scary how few people really understood what Dijkstra was saying. My best guess is that because most people learn programming backwards, IMHO, by starting with the languages and then learning higher-level logical constructs, like state machines or even lists or maps, it has permanently skewed their perspective.
My experience, after over 10 years as a system test engineer on software systems, is that poor software really is from a lack of discipline in starting with mathematical constructs before writing the code. I generally worked with very experienced programmers who didn't make a lot of language errors, like improper use of pointers, but were still tripped up by things like when to free allocated memory. The kind of errors that wouldn't occur very often if the discipline of using a mathematical construct like a hierarchical state machine was enforced. For instance, instead of starting with a proven state machine library they would just set flags and create an adhoc state machine that was riddled with problems.
"Meaningless!, Meaningless!" says the Teacher. "Utterly meaningless!"
It is funny to me how many profs talk like this guy wrote.
Today we are going to...
Later we will go over...
It actually makes you think this will be some type of discussion and not a dictation. I would have loved to respond and say
We think you are an idiot.
As for his work? Who really knows. Maybe WE can figure it out someday.
The more I learn about science, the more my faith in God increases.
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.
Bad teachers gets you
#1. cargo cult programming
#2. people bound to a language instead of logic
#3. not knowing why using an unsigned int in a for loop is faster than a signed
#4. using linked lists when an array would do just fine(CPU prefetch unit can't prefetch well with linked lists)
#5a. Unable to make multithreaded programs that always work(omg! my program works on my single/hyper-threaded cpu..)
#5b. programmers that don't know why hyper-threaded cpus won't truely show all SMP bugs
#6. SQL queries that take 10 minutes instead of 10 miliseconds
It's not just about making something work, but knowing why it worked and what way works best
Dijkstra's Cruelty is the nickname UT cs students gave to the course his wife taught. It was a required course when I was there and it was 2 semesters long. I think it was called "Software Development" but should have been called "Fantasyland Development". Total waste of time and energy. I never saw him on campus, except maybe at graduation.
The best classes were given by people who either were working in the real world or had some experience in the real world and were trying to get their masters or doctorate. The 'professors' going for or having tenure were the worst.
Back in the day, we learned Fortran, assembly and Algol all in one semester. No spell checker on the cardpunch machine either!
(Actually, it worked pretty well as a foundation course.)
The part about needing multiple personalities reminded me of doublethink from 1984.
oh, car analogy, maybe he is a genius, or maybe he just likes to blow his own horn.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
Last I checked, no one had quite figured out how to teach computer science -- your first course in college would serve mainly to flunk those who didn't know, or couldn't learn very quickly on their own, because the course itself certainly isn't going to teach you much.
However, the specific things Djikstra is talking about are not problems.
Consider his insistence that "bugs" should be instead called "errors", because this is less metaphorical and closer to the truth -- placing the blame where it belongs (the programmer), and allowing a lower tolerance -- a program cannot be "mostly correct"; it is either correct (with no errors) or it is incorrect (has errors).
This is to ignore one of the most important things to understand about modern computer science: Culture, or, more importantly, communication.
"Error", even in context in computer science, could mean several things. It could be programmer error, it could be an error in the rest of the software, it could be a hardware error, or an error status returned from any of these, even user error.
"Bug" has a very specfic meaning. When you say you've "squashed a bug", there is very little doubt as to what you mean.
Yes, it was initially attached to a metaphor. But as Djikstra so clearly points out, computer science is a radical novelty -- and such radical novelties tend to borrow words from older vocabulary, from other languages, from fiction, and invent some of their own. They do this not because of intellectual laziness, but because they need a vocabulary of their own -- yes, jargon serves a purpose.
And yet, it is not such a radical novelty that old ideas will have no effect. Certainly, some understanding of mathematics will be beneficial -- and although calculus may not be needed most of the time, the way in which it forces you to think will exercise the same parts of your brain that tough programming will.
I would argue, though, that computer science is not only informed by mathematics. It is also informed by softer sciences -- philosophy, creative writing, and languages.
Certainly, parts of it are very much a hard science -- the best sorting algorithm for a given situation, for instance -- but these are often confined to small, easily replaced cases. After all, it should not be difficult to swap sorting algorithms in most programs.
Other parts are very much a creative work -- an attempt to find the clearest possible way to express an idea, both to the computer, and to the next programmer. It is here that we most often talk about elegance.
Both are necessary -- without the creative structuring of a program, and proper communication of that structure to all involved, we would not be able to swap sorting algorithms at will. Without a clear understanding of how the performance of a program is impacted by various choices, that beautiful, creative code may never run.
And that is why it is so challenging to teach. A good programmer is going to be using both halves of his (or her) brain, if not at the same time, then certainly throughout developing a given program.
And that is also why it's not going to be easy to learn.
If Djikstra were alive, he could learn a thing or two from Why The Lucky Stiff.
Don't thank God, thank a doctor!
You didn't provide proof to back up your examples, so you ask us to accept that explaining
cout << "output" << endl;
is incredibly easier to explain than
System.out.println("output");
In truth, the explanations for both are very similar, with the first you indicate that the << operator puts something into the left hand side which happens to be the output to the screen.
In the Java version you indicate that the System has an output device called out and you ask that out device to print on a line the string "output".
Why the Java version is superior is because in the C++ version you immediately run into a major issue: How does the string get a endl put into it? To explain that you then need to explain that << is an operator which is implemented on the cout device, which then returns another invisible reference to the cout device that will also accept the endl when the << operator is called on that.
Certainly neither is above the ability for an undergraduate to grasp, but saying that the Java version is harder to explain just shows a bias for all things familiar. I too miss the << syntax from C++ when programming in Java, but it's insane to say that the cleaner syntax results in more easily explainable programs.
As far as garbage collection, that's easier to explain in Java too. Since Java implements only one means of garbage collection, its explanation only takes a couple of hours. C++ has two means of objects consuming memory, one that is rigid enough to explain in an hour and another that is a "figure it out for yourself" solution. Best practices must then immediately be taught, which reduces the number of ways malloc / free can be used "safely".
I've see precious few programs which were competitive on the grounds of their improved garbage collection / freeing mechanism alone.
Perhaps you should read that Dykstra paper carefully, as you seem to have fallen into a trap or two he describes. That said, I wholeheartedly agree with you that the current educational process has a lot be desired for Computer Science, but sometimes I wonder at the utility of a College that does not offer some job training in this age.
Employers look to college graduates expecting them to be trained and have created a huge demand for graduates as a result. Due to the "everything for nothing" culture in the USA, those same employers make it clear that they want pre-trained employees. Colleges react in kind by expanding their enrolment and providing skills that make them competitive in the eyes of their prospective students for the purpose of obtaining a desirable job. Thus the system becomes more a job training centre each day, which is inconsistent with the loftier goals of a College.
Lofty goals are called lofty goals because they are hard to achieve. Colleges of lesser moral fibre will play lip service to such goals and mostly do what industry wants. Colleges of stronger moral fibre will uphold such goals and risk losing credibility with the future hiring base and likewise their future student body. Only a few truly exceptional Colleges will ever be able to disregard the collective employer pressure; like the Computer Science program Dykstra was enjoying. For the masses, environment shapes the subject to a greater degree than we might like.
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.
An engineer still needs to take quite a bit of physics.
I don't want an engineer who doesn't know what "specific heat" means, and I don't want a programmer (whatever you call him) who doesn't understand computability and complexity.
Then again, maybe it's just because my team has alternating making me want to kill them and myself for the better part of the semester...
You're ready for a job in the software industry!
IMO there needs to be a starker contrast between computer science and computer engineering, just as there's a contrast between "real" engineering and, say, physics.
Those who just want to be able to program, who are focused purely on employability right out of college, can look for computer engineering courses teaching the popular programming languages. These people can be fine programmers, ready to start... so long as the language popularity hasn't changed by the time they graduate. It would be sort of advanced vocational program, just like any other engineering.
But the real scientists, those who want to experience and express code on deeper levels, should be looking for something very different, that which Dijkstra describes. Just as a scientist and an engineer can work on the same project contributing different skills, the computer scientist has his place even in the real world.
The two really are different mentalities, and it seems that the mixture of the two leads to situations that are non-ideal for either.
Yeah, I know. What can I say? Sort of a force-of-habit as I'm a bit used to another (very lousy) forum (that I have no control over) which splices a supplied standard urls ("too long a word for input") into smaller chunks.
For those of you who are playing at home, the TinyUrl points to http://lucacardelli.name/Fonts.htm
While I agree that he talks about many issues that effected the computer industry as a whole, I believe that society has worked through many of these issues. As an example:
(4) The military, who are now totally absorbed in the business of using computers to mutate billion-dollar budgets into the illusion of automatic safey.
The military learned early on that computers are not the end-all-be-all to combat. It still take grunts on the ground to win the battle. Computers provide a means of sorting information. They are nothing more than a tool much like the riffle is to the infantry. (Sorry, I had to use one of those analogies that Dykstra is so fond of hating.)
Another thing Dykstra talks about, is that society changes at a slow pace. This too is a paradigm shift. While we were, at one time, accepting of change over generations. With the advent of the internet most of society now accepts change in the terms of just a few years. (ex: How long did it take Wikipedia to become accepted as a reference for college papers?) It is the ease of which we are able to pass on information that has allowed this to happen.
Some days I get the sinking feeling Orwell was an optimist.
Bachelor degress have become a fluid generic form of certification. The first degree attained mostly by the efforts of the student, independent of their family. At least intellectually. Financially its a totally different matter. The purpose of that certification is usually a job interview if not the first job. Its unfortunate that only then does the student truly become aware of their job function and duties, and sometimes they are very unhappy. But what does this have to do with the essay at issue? I think it has to do with the rather elitist point of view that education exists for the the sake of education. That somehow being exposed to this way of thinking is better than another. Were this an essay on a graduate level topic it might have more merit.. and being a topic for the 80's perhaps it was more relevant then. But today with the cost of education so high, and more and more being carried by the student, I think it better the education programs advertise themselves as experimental or career oriented, or carter to, the job market.. and business. Being an educator is not a license to experiment on a person or their potential to make a living, or payback their student loan. It bothers me to think that as a student there was a time when I was purchasing one of the most expensive things I ever purchased in my life with little experience, and to think the person I was purchasing it from.. want to endow me with their point of view of the world just because they could.
It was a Dijkstra joke.
Check it out, the first page is numbered "0"
I'm a 2000 man.
We get Lenny. And you're nuts.
Everyone who is arguing against Dijkstra and saying that programing is about engineering, not writing formulas or proofs, remember your words when the software patent debate pops up again...
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
There is nothing more fascinating than learning how computers really work.
Yes, there is: learn how reality works. I am a physicist and nothing beats the feeling when you get some insight on how the universe behave
-- dnl
Computer Science is larger than understanding how computers work. How about understanding how people work with computers?
Agreed.
Yes, Engineers understand math, at least to some extent. (I was surprised in grad school about how much more rigor was possible compared to doing the same material as an undergrad or high school student :-) And some kinds of engineers use appropriate math for what they're doing. Dijkstra's arguing here that software engineers generally don't. Sure, we'll occasionally apply order-of-magnitude math to our algorithms, deciding whether an N**2 or NlogN is a better choice for the size of data we're dealing with, but computer scientists have been bitching about the lack of use of program-correctness proofs for at least a decade before Dijkstra's talk, and even though our computers are 4 orders of magnitude faster and 6 orders more price-performing than when he wrote the talk, we still consider that stuff too inefficient for practical use and write lots of buggy code.
A simpler example than proof-of-correctness is input validation. A program is designed to take a given set of input and produce corresponding outputs, so one way to improve program correctness is to start by specifying the input set and validating whether the input the program receives is in that set and reject it if it's not. (Replaces "Garbage In Garbage Out" with "Garbage In Error Message Out".) My CS100 professor emphasized that ~30 years ago and made us run all of our homework programs on maliciously designed input, but how many of the security bugs you see today are still buffer overruns or stack smashing or other because people aren't bothering to define and enforce the valid input sets. It's improved a bit with object-oriented programming because objects are a bit more restrictive in what kinds of input they'll accept, and many of the popular objects validate their input and are almost as easy to use as similar objects that don't, as opposed to rolling your own lazily or using C's getwhatevers().
I partly blame Knuth for this :-) His books were the canonical algorithm books for a generation, and did the math really really well, but did programming examples in a baroquely ugly assembler language or spaghetti-pseudocode when better languages were available (e.g. Algol or cleaner assemblers), and that made it hard to learn how to apply his mathematical techniques to real programming.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I personally just endured a semester of java (software construction) where the assignment was fun (game of life on a 2020 board) and I enjoyed writing the code. The lecturer then marked me on the running application and didn't even read my (in my view well commented and probably naive code) of which I was a little proud! The exam then had lots of boring stuff that he was droning on about in the lectures, I asked about a concept in an email once and was given links to a website from 2000 !!! Surely even java has changed a fair bit in 8 years?
So my point is python is better at simple code, lets move CS courses to python and even contributions to real world OSS applications.
"And JavaScript takes all that and gives you LISP power" - by 0xABADC0DA (867955) on Tuesday December 02, @12:17PM (#25961763)
Correction:
"AND JAVASCRIPT TAKES ALL THAT AND GIVES YOU VIRUSES/SPYWARE/TROJANS/ROOTKITS/MALWARE-IN-GENERAL ON THE INTERNET NOWADAYS, & 95% of it"
That'd be FAR more accurate, unless LISP is an abbreviation for 'Live Internet Suckers for Prey' or something that is... lol! ... & anyone here is free to verify THAT statement/correction of the person I quoted of mine, over @ SECURITYFOCUS.COM &/or SECUNIA.COM (as 2 security based websites that track that type of information), anytime, to check its veracity.
Above ALL else? FIX THAT JAVASCRIPT DOM (document object model)...
Edsger Dijkstra, the greatest computer scientist to never own a computer
Dijkstra did own a computer. He bought a Macintosh:
"Even after he succumbed to his UT colleagues' encouragement and acquired a Macintosh computer, he used it only for e-mail and for browsing the World Wide Web".
Source: U. Texas CS Department (In Memoriam): http://www.cs.utexas.edu/users/EWD/MemRes(USLtr).pdf
I'm not sure I fully agree with the article. Metaphors can help in better assimilating new knowledge by making it more natural to work with. Think about what object orientation has done for programming. If we had done as Dijsktra suggests and approached software engineering with an "open mind" maybe we would still be coding in assembler, as that is the "purest" way to interact and think the way computers do.
What does this word mean? I googled it, and all that was returned were copies of this article.
"That which does not kill us makes us stranger." -Trevor Goodchild
While this langauage has been implemented...MIT's Scheme is pretty close to a programming language that will never be used in the real world. I thought that it was an excellent way to learn programming outside of the other more practiced languages. There are two problems with his arguments. 1) It doesn't matter if schools press for their students to push their knowledge outside of their comfort zone. There are a wide range of educational offerings available from community colleges to private Unviersities. Students usually try to select their educational challenge based on a wide variety of factors. Prof. Dykstra discussed that the universities should push the students beyond their comfort zone into these radical novelties. Maybe he was teaching at the wrong school. Or maybe he was compelled by his department to dumb down his curicula, but I seriously doubt that every CS department tries to dumb down their education the way he described. The free market let's students decide the type of education they would like. If they want a CS challenge, there are plenty of offerings out there. 2) Not all people are as smart as Prof. Dykstra would like them to be. Even if you found a person with an 100 IQ that was interested in learning higher level abstract mathematics and their application to programming, that person would not be suitable for this education. Most people are very capable of self determining the maximum level of intellectual challenge they are up for. Even if they can't afford to go to some of the more expensive private universities, someone that is very intellictually capabale but financially challenged should have a very wide variety of resources available, including unviersity course access via the Internet.
What about a ^= b, b ^= a, a ^= b (for integers)?
Needed? So why didn't the world fall apart when the fandangled realtime airline-pricing-optimization system got delivered two years late, way over budget, and full of bugs?
Twenty years after Dijkstra wrote this, the situation has not improved; arguably it is worse. Programming has changed from a mere craft to sorcery. How do we solve a problem now? Consult the oracle of google, randomly select an entry, and cut and paste some magic code or call some totemic library. Still doesn't work? Chant some testing incantations. After a while the customer decides that they've run out of time, and decides that near enough to spec is good enough (after all, the spec is not very formal, and can be stretched to fit the program!).
Sure, I'm exaggerating. But when nine out of ten 'software engineers' don't even know what an invariant is, there is a failure of education. Especially now, when most programmers are not coming out of elite universities (which still teach computer science), but out of tech courses.
No, we don't use formal principles to design our complex software projects. But it isn't because time doesn't permit. It is because we don't know how to.
We call it software engineering, but traditional engineering does work from formal principles, and then refines the parts of the construction. We know that doesn't work for software, because of orders of magnitude more complexity, and interactions between parts of the system. Symbolic digital computation is a paradigm shift.
Why does it matter? Because we aren't just talking airline systems. Twenty years ago the big deal was the missile defence system 'star wars', which was to be a larger software project than anything in existence at the time. The potential harm from the failure (at runtime) of such a project is not worth contemplating. Maybe your airline system is not important (!), but some of us write code that has life threatening consequences if it fails. So we welcome any advancement in the theory of programming, and in the teaching of that theory.
Goedel's Incompleteness Theorem actually doesn't hold for any description of human knowledge. For example, one of the first premises of the theorem is that the field of possible symbols is finite, which isn't true of human knowledge. There is always another symbol to represent a new idea - actual human knowledge is an open system.
There are other objections, but that's simply the most basic (and obvious).
That's all fine and dandy. But how to teach people about electrons?
Without analogies to properties of electrons which are wave-like or particle-like, how do you say anything useful about an electron to anyone who isn't already a particle physicist?
Ayn Rand said it well, if your base premises lead you to contradiction, you must examine your premises. Rather than be driven crazy about how an electron can be like two things which are as different as a particle and a wave, you should question your assumptions.
Are particles and waves so different from each other? And why should there be any dissonance in any one thing having properties of both? I have the accented english of Arnold Schwarzenegger and the physique of Danny Devito. Are you now driven crazy on how I could be like two such different people?
At Georgia Tech, when Greenly was in charge of beginning programming for undergrads, cruelty was the norm, and I think it probably made better programmers out of the bunch that squeaked by. Added pain was Nick Black, but that TA was legendary for other reasons.
Shout out to Phat Joe.
Dijkstra is right that you need to teach mathematical formalism to students. He is wrong when he says it has to replace the practical teaching of languages and tools. I was taught in his school of thought, and I have had a lot of catching up to do. I'm really good at architecture issues and deriving an algorithm is a breeze, but it has taken me a long time to learn the "carpentry" skills of programming. They were scoffed at in the CS dept of my university, and I believed what they said for a long time.
These days I do test driven development, a discipline that is heavily derided in Dijkstras paper, and it is the best practice I have learned in software development. His thesis is that when you have proven that your program fulfills the formal specification, your work is done. He forgets that the specification can be, and usually is, wrong. The hard part of programming is to produce and interpret the specification, not to implement it.
Stroustrup is wrong (or perhaps over-enthusiastic about teaching C++ to beginners). If it were any other language, sure, but using C++ for anything but trivial applications without a knowledge of C is an exercise in futility.
For example, you can't use "new" for anything (other than wasting memory) without using pointers in C++, so one better have some semblance of an idea about how pointers work before trying to write anything that doesn't look like a FORTRAN program.
The problem is that (for all its benefits - and there are many), the design of C++ is forever compromised by the requirement to be backwards compatible with C. String literals aren't strings, they are *pointers* to a series of signed eight bit integers. When new objects are allocated, by default they contain random garbage data. No array bounds checking anywhere. Does a language really need both references *and* pointers? Other than backward compatibility?
I wouldn't dream of teaching C++ to anyone who didn't have a working knowledge of C, because using C++ to do anything worth the extra complexity of the language requires it - and a lot more.
It's wrong to say that one has never owned a computer. Most humans do have computers, because our hands are computers. Our brains are also computers, as are our whole bodies. Computers are everywhere, even in non-living things, if you know how to recognise them. In fact we are living in a huge computer. So, the summary should say that he has never owner a digital electronic programmable personal computer.
I had Dijkstra at UT. I got my butt kicked. I'm still getting my butt kicked.
>Imagine that, a mathematician describing engineering as deriving a formula!
>No comfortable analogies here...
That's not an analogy. That's literally what computer science is. That you did not know that says a lot about why he wrote that article.
They didn't decide that merge sort was a correct sorting algorithm by coding it up and running it a million times. A mathematical proof was given. No actual running computer is necessary.
Furthermore, a computer program *is* a mathematical formula. It always has been. Dijkstra is pointing out that the curriculum has been so dumbed down that most programmers don't even know that.
In this article Dijkstra correctly criticizing the fact that most programmers don't know how to prove the correctness of algorithms. The same could be said about asymptotic complexity. Most programmers do not understand these concepts well enough to write programs that don't run forever on large input values. This is a real problem.
There are both analytical and empirical methods for dealing with computer programs. The analytical methods involves proofs of correctness and symbolic manipulation. The empirical methods involve software testing and debugging.
Dijkstra certainly goes overboard by suggesting that software testing is totally unnecessary because he's not interested in such intellectually uninteresting problems as reliably detecting typos in 10 million lines of source code for a problem. Dijkstra correctly points out that software testing suffers from the fallacy of induction, but ignores the fact that induction is an important tool even if it doesn't prove anything.
The truth is that most programmers are just code monkeys with no understanding of the *science* in computer science. That is what Dijkstra is railing against ultimately.
>Oh woe! Not having to worry about pointers and having built in string types.
>I love C. It's terse and really useful for optimising performance but it's really not a good teaching language.
C is an excellent teaching language. It has a relatively simple syntax, and doesn't hide anything under the covers. In a similar way assembly is also an excellent teaching language.
It teaches the user about memory addressing and memory management, which are important topics no matter what language you use. It also teaches the user how to do the elementary logic and understanding of flow control that constitute the early stages of learning how to program. It does all this without forcing the learner to memorize unnecessary syntax.
Conversely, while C is an excellent teaching language and a poor language for real world use, C++ is an excellent language for real world use, and a poor teaching language.
I expect there will be some inane comment about how C++ sucks from someone who tried it once and thought it was too hard to learn how to use. My response is simply, "don't be such a baby." Real programmers use C++.
On the contrary Dijkstra is entirely right on this score. I started with Basic and it took me years to understand the need for understanding formal methods and more, much more time than it should have to learn to properly apply them if I'd learned from the beginning.
It's very easy to switch from writing proofs along with your code to writing the sort of stuff you typically see in on the job. It's nearly unheard of for the sort of hack (not hacker) that was weaned on Basic to either understand or understand the value of experience with formal methods.
Sneering at formal methods (I know, formal methods are not a panacea) is prima facie evidence for being a typical head-up-arse hack who sits next to the person who brags about the emphasis their software engineering curricula put on soft-skills like use case analysis, user interface design, project management and finance to the detriment of actually understanding what a computer is and what it might be good for and what it might not be good for.
It's amusing to note that while computer science is not an engineering discipline, those soft skill topics aren't a major emphasis of any other engineering bachelors curricula either. That's not to say that those topics are irrelevant to the job, there just isn't time to fit that in and still end up being an engineer.
If you won't buy this argument from me an anonymous coward, then buy it from Carnegie Mellon whose reputation as a software engineering school is pretty much solid gold. Those folks teach formal methods from the beginning.
http://www.cs.cmu.edu/prospectivestudents/undergraduate/index.html
It's interesting to note that Carnegie Mellon's justly famous Software Engineering Institute *doesn't offer* a BS or any other degree and is managed separately from any academic department.
So, his Macintosh wasn't a computer?
It couldn't have been his, you know, personal computer ;)
I may be mistaken in this (my degree is in physics, not computer science) but it has occurred to me that computer science is, in fact, a science. If you want something ultra-practical, go take some vocational classes or something of that sort. If you want to be a server admin, many tech schools now offer information technology programs. If you want to develop software, it seems to me (though correct me if I'm wrong) that the best path to pursue would be software engineering. Computer science is, under my understanding, supposed to be that area of science concerned with topics like the theory of algorithms and Turing machines and so forth, and not so much with such mundane details as to what particular line delinimination is used in such and such a language or what protocols are now supposed by Windows Vista. Physics, chemistry, and biology do not strive to be their engineering counterparts; why shouldn't computer science be just as abstract? (and I suppose, on some level, just as useless?) Besides, my understanding is that the point to having the abstraction is that when faced with potentially new systems, those with CS degrees won't be obsolete or incompetent.
> try to get away with the concepts we are familiar with
i assume he meant "get away_from_" but maybe he was just trying to get away with something;-)
"I can actually now use a computer, unlike much of the coders I come across" - by noldrin (635339) on Tuesday December 02, @09:58AM (#25959423)
Then the people you meet calling themselves coders aren't. Coders make it possible for you to have the programs you USE, Mr. user. Who is the moron who modded this fool up as "insightful"?? I strongly suspect he modded himself upwards that way via an alternate logon, or that people at this website are fools also, especially if they do not realize the very simply point my first sentence makes, which is common sense.
I agree with ted, mostly because I am in the same boat as him.
One difference though, when I did my CS degree I had a teacher who taught my C, C++, data structures and algorithms classes who did not hold you to the math prerequisites to the class. This guy used to be a math a physics teacher, and his reason for not requiring math was simple, "you are using logic, not math to program". He said why invent the wheel if it is already there. That is not to say he was an easier teacher. When we did data structures and algorithms in C++, we were not allowed to use stand template library. We had to do everything from scratch, including pointer arithmetic.
Was it a bitch of a degree to get, yes. Would I do it again, yes.
Call me a masochist.
What about Konrad Zuse? You are clearly forgetting Zaphod Beeblebrox!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
If you weren't anon and this a couple days old, I'd say mod parent funny!
What's wrong with the world can largely be attributed to the usual things: Chinese, Russian, and American policy on a wide variety of subjects, plus petty-minded xenophobia that keeps the Hutus and Tutsis, or Palestinians and Israelis, at each others' throats. Nothing to do with how we teach computer science, I assure you.
I piss off bigots.
After BASIC, I was glad to encounter programming languages that could be used to solve complex problems, and made it possible to understand complex programs.
So the dead Dijkstra was wrong, and the living Dijkstra is right.
I think you're missing the point. Yes, the program is fairly easy to write. The issue is that it will take a very long time to run on problems of non-trivial size.
"The use-mention distinction" is not "enforced here."