On the cruelty of really teaching computing science (1988) [pdf]

https://www.psy.gla.ac.uk/~steve/educ/dijk/EWD1036.v4.pdf

by teawhoyou • 6 years ago

89 120 6 years ago

psy.gla.ac.uk

williamstein• 6 years ago

Should say 1988 in title.

dang2• 6 years ago

Added. Thanks!

redgrange• 6 years ago

Can someone summarize? I couldn't follow this but given the author, it sounds like something i should pay attention to as a budding educator

throaw17122020w2• 6 years ago

If you can't follow, why care?

KMag3• 6 years ago

Such a fatalistic view of human understanding helps no one.

"couldn't" is past tense. The GP clearly expects/hopes there's a quick remedy here, and your reasoning about "can't" in the present tense (and implied continuing future tense) doesn't hold.

zachdaniel3• 6 years ago

No need to be rude.

cratermoon2• 6 years ago

Computers and programs are really complex; programming is really hard; Programming (computer science) will eventually be able to replace human reasoning (and be better at), but the complexity to do that requires deep mathematical knowledge and formal methods (Djikstra was a big fan of formal program proving). Universities aren't teaching computer science, because businesses don't care about that, they just want coders.

I took a few computer science courses at UT back when Djikstra (not from Djikstra himself, though, from Dr. Nell Dale) was there. Everything in the algorithms class came with formal proofs. Loop invariants were core concepts. The book was not yet published, we spiral-bound photocopy of the draft.

ausbah• 6 years ago

banking on computers to automate human reasoning anytime in the near future is laughable at best, utter naivety at worst

sjg0072• 6 years ago

Both my undergrad and grad education did not train me to program. I did learn computer science though. Even then... mathematical and algorithmic proofs are in a league of their own. CS has always been applied math as much as physics is.

KMag3• 6 years ago

[I've incorrectly put some of the statements from Part 2 in the Part 1 summary, but I've already sunk enough time into summarizing, and the flow feels a bit better this way.]

Part 1: definitions and motivation.

"Radical novelty" describes something new that is so different from everything that came before it that analogical thinking is misleading and new phrases built by analogy with old phrases are inadequate at best. Thinkers in the middle ages were greatly held back by over-use of analogies. There are many cases where modern society has dealt poorly with radical novelty: relativity, quantum mechanics, atomic weapons and birth control pills. The way our civilization has learned to deal with great complexity is to specialize professions, where each profession abstracts away some amount of information, typically expressed in the range of physical scale of their work. The architect deals with a certain amount of complexity: not having to deal with the large scale of the town planner or the small scale of the metallurgist working for the I-beam manufacturer (my interpretation of "solid state physicist" in this context). Computing is radically novel in the scale of complexity handled by a single profession. The terms "software maintenance" (as if time or use alone, rather than shifting requirements, degraded software), "programmers workbench", etc. are evidence that analogies are misleading and software is radically novel.

Part 2: consequences [this summary is more abbreviated than part 1]

History has shown the natural human reaction to radical novelty is to pretend analogies still hold and to pretend that rapid progress isn't possible. We can't keep treating software like it's just some kind of mechanical device and programmers as assembly line workers stamping out widgets. We can't treat software production as just a new type of manufacturing. Manufacturing-style quality control (testing) is a misleading analogy for software quality control, and formal methods are needed for software. Software engineering isn't about designing new widgets, but about fixing the impedance mismatch between humans as assigners of tasks and computers and executors of tasks. There are a variety of vested interests (Mathematicians, businesses, the military, those teaching software development as widget building, etc.) working against advancement of Computer Science as a field. We need to start by fixing our terminology to stop encouraging misleading analogies. ("Software bug" encourages us to think of programmer errors as things that passively happen, like insects crawling into relays, etc.) The job of a software developer is to show that their designs and implementations are correct, not to correctly execute some set of operations that create a software widget.

dang2• 6 years ago

If curious see also

2012 https://news.ycombinator.com/item?id=3553983

2010 https://news.ycombinator.com/item?id=1666445

2007 (a bit) https://news.ycombinator.com/item?id=43978

samth2• 6 years ago

A useful counterpoint: https://computinged.wordpress.com/2020/12/07/dijkstras-truth...

amw-zero5• 6 years ago

I didn’t find that useful. He’s not arguing that metaphors and anthropomorphism are not effective for teaching in general. He’s arguing that they hide the underlying mathematical and logical objects that programs represent, which lulls programmers into a false sense of accomplishment.

I agree. We are awfully good at creating software that does not function properly. Should that be rewarded?

samth2• 6 years ago

This is similar to saying that instruments "hide the underlying physical objects". That's certainly true in a sense, but also not a helpful point -- we can't see stars or proteins or quarks without instruments. And we can't learn without metaphors.

tmp538394722• 6 years ago

Same thing but in his own handwriting:

https://www.cs.utexas.edu/users/EWD/ewd10xx/EWD1036.PDF

I know it’s silly, but it just made him seem more human to me.

vulcan01• 6 years ago

Off-topic:

Damn, how do people get such good handwriting? It looks typed at a first glance. Wow.

raegis• 6 years ago

Practice :)

abdullahkhalids2• 6 years ago

There is probably a significant genetic component to it. Some people have better eye-hand coordination and better hand stability.

wdevanny• 6 years ago

Dijkstrta is infamous for his focus on handwriting. A student once told a story that during a 1-on-1 oral exam, Dijkstra spent half the time having the student practice their handwriting.

fnord77• 6 years ago

I practiced and practiced as a kid

carapace2• 6 years ago

What I find really impressive, almost galling, is the lack of corrections. Thirty pages and (i counted only) one scratch-out!

cmroanirgo• 6 years ago

I agree. This should be the main url.

I find it ironic that a hand written talk (by Dijkstra no less!) begins:

The second part of this talk pursues some of the scientific and educational consequences of the assumption that computers represent a radical novelty.

Even doubly so, that the OP pdf was clearly transcribed and then converted to a pdf, when the original is so very much clearer to read.

vincent-manis• 6 years ago

I have very mixed feelings about EWD. On the one hand, his work on concurrency and formal methods has had a profound impact on computer science, and we owe him a huge debt.

On the other, I was present at an IFIP talk he gave in Toronto in 1976 where he announced that personal computing would go nowhere, because the average person cannot program.

jdc• 6 years ago

He's not wrong in the man-computer symbiosis sense.

izgzhen• 6 years ago

The fact that average people can write useful programs are largely due to the maturity of software engineering practices, which was just beginning to develop at EWD's time.

Software engineering != developing algorithms. And unfortunately programming can mean both things.

shagie• 6 years ago

https://news.ycombinator.com/item?id=11796926

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." - Alan Kay

With the followup post from Alan Kay himself.

derekp7• 6 years ago

Even today, computers are useful to average people only because there is software that is available that solves a wide range or problems, combined with the fact that there is really only a handful of problems that people want computers to solve for them most of the time. Catagories like communications, document and media creation/editing, data storage and calculation.

But still, let's say there is a problem someone wants to solve, and it really doesn't take much programming to solve it? How do regular people that don't have access to a programmer use a computer to handle a novel problem?

To give an example -- There is a table game that is popular at Cracker Barrel restaurants that consists of a triangle shape with 15 holes, and 14 golf tees. The object is to jump over pegs and remove them, and go till no more moves are available. The goal is to get down to 1 peg remaining. Now how would you use a computer to solve that without writing a program? (This was back in my college days, however I recall doing a brute force program that tried all combinations, and spit out the winning ones -- turns out there was something like 15,000 winning strategies).

Edit -- a quick search shows that this has become a popular computer programming challenge, so there does exist choices that people can download, but there are other similar variations that someone may want to solve.

Edit2 -- apparently the generalized version of this concept is called Peg Solitaire https://en.wikipedia.org/wiki/Peg_solitaire

jstanley• 6 years ago

For the average person, the computer is still not the bicycle of the mind. The computer is more akin to public transport of the mind, in the sense that it works OK as long as you want to go to a common destination, but after that you just have to walk.

SulfurHexaFluri• 6 years ago

Future predictions are rarely correct. You can hardly fault someone for making an incorrect prediction.

rramadass4• 6 years ago

because the average person cannot program.

EWD was right in the sense of his definition of "Program" i.e. as a mathematical object. What he did not quite foresee is that it takes only a few intelligent folks to invent/design/implement the entire infrastructure so that the general "mass of programmers" can use those to certain profit without much mathematical background. This was how the "Industrial Age" played out, we use a lot of machines everyday without having an inkling of how they work. I think Dijkstra failed to realize that this was as true of "Software" as of material objects. In his defense, the "Software Industry" was still being invented at that time and hence nobody could predict how things would turn out in the future.

But his fundamental thesis that a "Program" should be treated as a mathematical object and proved using rigorous logic is still true and by that definition a lot of us fail the test. This is quite independent of the fact that the society at large has accepted a watered down definition of a "Program" with all its shortcomings and failures.

adwn2• 6 years ago

But his fundamental thesis that a "Program" should be treated as a mathematical object and proved using rigorous logic is still true

How is that even remotely true? How are you going to formally model a browser, or a word processor, or your mail client, or a 3D game, let alone prove it correct against that specification?

If we actually followed that requirement, computers would be almost useless today, except for a few tiny niches where millions of dollars in development costs for even relatively small programs would be justified. Keep in mind that your development tools would be meager to non-existent as well, since they'd also have to satisfy that overly strict requirement.

amw-zero5• 6 years ago

How is he wrong? The average person cannot program. The average person can use but not create software, that’s why computers are popular.

mkl• 6 years ago

He was wrong in that personal computers took the world by storm, to the point that almost everyone in modern civilisation carries one in their pocket. He was wrong in thinking that programming was essential to personal computing; it is not.

Animats• 6 years ago

"We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs."

Hewlett-Packard, in their glory days, had an internal policy to apply the term "defect" to both hardware and software. If it has defects, it may not be shipped.

moron4hire• 6 years ago

I do this in my own projects. Specifically, I have them defined as:

"Defects" are a deficiency in the project. They come about through a failure of process. We have to fix them, and fix the failure of process that resulted in them.

"Bugs" are anomalous behavior that get in from outside. A defect in a dependency or external service can cause a bug in my project. We have to fix them, which may require fixing the dependency, working around the bug, or ejecting the dependency completely (I like to call this "deprecated due to infestation").

"Glitches" are anomalous behavior outside of the specification of the system. Example: a user whose cable splitter outside is dangling from a single strand of wire, preventing them from having a reliable enough network connection to use our telecomms system. We might not be able to do anything about glitches other than improve user training.

And finally, "User Error" is a myth.

I find being able to evaluate and define issues by this criteria is really helpful in figuring out the best course of action to take with them. For example, when I realized I was spending the majority of my time working around Bugs caused by Defects in Unity3D, I knew it was time to eject Unity3D. It's kinda like Unity3D had bedbugs, and those bedbugs gave us unsightly sores. It was better to burn the bed completely than be constantly applying bandaids to the sores.

recursive2• 6 years ago

Maybe it's just because I've been dealing with them on a daily basis for decades, but when I hear "bug" I don't infer any different connotation than "defect". They both sound like an error in a program created by the human(s) who made that program.

Also, I don't understand the reasoning for why we shouldn't anthropomorphize programs. I read the digression about two and a half times, but I can't connect the chessboard/domino tiling problem to a reason we shouldn't consider software's behavior.

skytreader• 6 years ago

I can't make much sense of Djikstra's linguistic points either. But with the little I can understand, my objection boils down to the following statement:

A programming language, with its formal syntax and with the proof rules that define its semantics, is a formal system for which program execution provides only a model. It is well-known that formal systems should be dealt with in their own right, and not in terms of a specific model. And, again, the corollary is that we should reason about programs without even mentioning their possible "behaviours".

Perhaps this is another aspect of the "SWE vs. CS" debate but I've come to the conclusion that in SWE, it makes more sense to reason about entities and how they behave (deliberate use of the word) rather than in terms of every single line of code. Said another way, anthropomorphizing programs is another means of abstraction and SWEs and CSs alike should be comfortable going up and down the abstraction ladder as needed. Even in academia, outside your first two programming classes or so, outside algorithms, it is rare to spend time in the realm of "formal syntax and proof rules". (Or maybe this is simply a difference of the needs of CS education today and during Djikstra's time.)

But why should we encourage reasoning in this manner? I have many reasons but the bluntest (yet holds no less water) one is because I think Djikstra's statement assumes you have access to the readable source code. That's simply not true. So it's more useful to reason about computing units as entities with "behaviors".

amw-zero5• 6 years ago

He dislikes anthropomorphism because there is no real-world equivalent of logic, and he believes that we should attack the logic problem of software head-on. Creating a metaphor is great for abstracting what logic is actually doing, but it discourages focusing on the actual logic.

Basically the metaphor is an opiate. It feels good to think about, because turns an intractable problem into one that is intuitive. But it doesn’t actually solve the problem - only considering the logic does.

watwut3• 6 years ago

Origin of the word bug is that long time ago, an actual bug (as in animal) caused an error. Since then errors are called bugs, because everybody loved the story.

I have no idea whether story is true. But, at Dijkstra time, he probably associated "bug" with above story - the error was not human mistake, humans were innocent, it was just bad luck that rarely happens. We are now 40 years later and associations are completely different.

bonoboTP6• 6 years ago

In my CS university software engineering course we defined several versions with different meanings: error, fault, defect, failure, etc. Some are about the programmer doing something wrong, some are about what the code itself contains after this, others about the actual event when the problem gets triggered etc. I forget which was which. Something like the error is what the programmer makes, the failure is what happens when it gets triggered when used, the defect is the thing in the code (colloquially: bug) if I remember correctly. No idea what "fault" was.

remolacha• 6 years ago

We don't need yet another step on the euphemism treadmill. Say "defect" long enough and eventually it represents the same idea as "bug". I have an instant negative reaction to the idea that "if it has defects, it may not be shipped ". Any moderately complex piece of software is guaranteed to have bugs. The action space of ex. a modern OS is way too big to test every possible code path. I'd rather have an OS with a few bugs than no OS at all. Move fast and break things (unless you're writing code for a space shuttle).

ht_th• 6 years ago

I have an instant negative reaction to the idea that "if it has defects, it may not be shipped ". Any moderately complex piece of software is guaranteed to have bugs.

Yes, but if there is a known defect in your software, do you release or not?

To me, there is a difference between knowingly releasing faulty software or only after release discovering faults in the software. Unless there is no reasonable quality check in the software development and release procedures, because then you are not doing much better than knowingly releasing faulty software.

watwut3• 6 years ago

We don't need yet another step on the euphemism treadmill. Say "defect" long enough and eventually it represents the same idea as "bug".

The original point was that bug is euphemism for error. In 99.99% of cases, errors are not caused by insects.

Dijsktra basically wanted to take step back on that treadmill and use proper word.

lapinot2• 6 years ago

Do you realize that you're plain in what Dijkstra criticizes? All you say is being contered in the talk.

[..] way too big to test every possible code path

He disregards tests. Most are futile. Maybe automated testing could make some sense (fuzzing, quickcheck, etc), but still, most are stupidly weak and offer no guarantee whatsoever (even quantitatively).

I'd rather have an OS with a few bugs than no OS at all.

He specifically argues for error instead of bug so that we can't say it's "almost correct" but only that it is "wrong". "a few bugs" is just "wrong".

kache_• 6 years ago

Technology advances much faster than language and culture can.

ibraheemmmoosa• 6 years ago

Man, he was in a bad mood that day.

"The effort of using machines to mimic the human mind has always struck me as rather silly: I’d rather use them to mimic something better."

zachdaniel3• 6 years ago

Ultimately it seems strangely exclusionary to draw lines in the sand like this. Everyone who learns how to program doesn't need to A.) be god's gift to the science of computing and B.) have the same level of understanding/fluency in what they're doing.

It's like saying the only way to teach any amount of a language is to require 6 months of total immersion. There is value in someone taking on year of a language and learning a few phrases, and moving on. Ultimately, people have practical and immediate concerns, like getting paid and putting food on the table. We aren't all programming for the same reasons, and sometimes getting the job done is all people have time or even the inclination to do. And we shouldn't judge them for that.

I'm not suggesting that he is entirely wrong, but reading things that sound like proselytizing just make me sad. There is so much room to educate and come to mutual understandings. Some people might think they've found a better route or a deeper understanding, but treating the rest like idiots is the best way to make sure they never get your message.

username904• 6 years ago

You want those lines though, glue software engineers tend to get really bitter when they get quizzed on computer science stuff, so it is in their best interest to draw the line instead of arguing that they should have the same title.

rxhernandez• 6 years ago

There is far more to writing correct code than knowing the contents of undergraduate computer science inside and out; there is an entire world of software engineering where undergraduate computer science theory is damn near meaningless.

I mean, I worked at a medium sized medical device company (10,000+ people) (who was considered the gold standard of their industry in many respects) where you would be hard pressed to find a single person that wrote a lot of code who had anything but a Physics, EE or CpE degree; I honestly can't remember a single person who had a CS degree despite being on an algorithms team.

I can't even remember a single person at the scientific device company I worked at where their algorithms team had anything but PhDs in Physics.

zachdaniel3• 6 years ago

This highlights something interesting for me: I've literally never heard anyone "arguing" that they should have the title of "software engineer" or "programmer" or "software developer". I don't know the history of it, and it could easily just be something that I haven't personally witnessed. Ultimately I fall into the camp of someone who would do fine getting quizzed on the computer science stuff, but at the same time it is ultimately about adding value (at least, when we're talking about someone paying you to work for them).

There aren't two camps: "glue software engineers" and "computer scientists". There is a spectrum of people with varying abilities in a wide array of sub-fields.

antegamisou• 6 years ago

glue software engineers

Where do you put the line between them and “purist” SWEs?

Even Things like

  #include <stdio.h>

already make you a gluer.

chriswarbo• 6 years ago

I like the analogy that English writers don't have to be at Shakespeare's level; even being able to write a shopping list is a very useful. Hence it's a good idea to teach everyone reading and writing at school.

I think the programming equivalent of a shopping list would be something like a simple 1, 2, 3 cron script, or if-this-then-that event handlers. That only needs a very basic understanding of computing (and how to find information effectively online), but opens up lots of really useful automation, e.g. backing up files, sending an email (e.g. a notification/reminder to ourselves), etc. Even without some automated API to use, a sequence of 'print' and 'sleep' commands can be useful to help ourselves/others perform some common task, e.g. a receipe which tells us when to turn down the oven, when to put on the pasta, etc. Hence I think it's a good idea to have simple 'learn to code' classes in schools; whilst more advanced classes would be optional for those wanting to specialise down that path.

coddle-hark2• 6 years ago

I would go even further and say that the most important aspect of teaching programming in schools is simply exposure. Most people don’t stumble upon programming in their day to day lives, especially now in the age of iPads and other locked down devices, so it’s important that the subset of population that would be good programmers are given the opportunity to at least try it out early in life.

rimliu• 6 years ago

The best cure for optimistic thinking like this would be simply to try teach some of that to _not_ self-selected group. It becomes clear very fast, how non-trivial "trivial" concepts are.

auganov• 6 years ago

I like the analogy that English writers don't have to be at Shakespeare's level; even being able to write a shopping list is a very useful. Hence it's a good idea to teach everyone reading and writing at school.

Language "skills" are strongly social. Literary acclaim falls squarely within celebritydom. Your ability cannot be too far off from the mean or else few will understand you. Though there may be some unmeasurable internal utility as a thinking tool.

We learn to read and write to do it as well as our peers do. This covers 99% of the utility.

There may be a social argument for programming, software is eating the world and having some shared understanding may be useful. But clearly technical ability is much less socially bound. The point at which you stop getting extra utility is very far from the mean.

timkam• 6 years ago

From a computer science perspective, this is an interesting piece. But from a practical perspective, I doubt that the Dijkstra of 1988 has a good understanding of the sociotechnical reality of the present day software industry. I comment (quite obviously) not to disparage him and his outstanding achievements, but rather to highlight that we cannot expect that Dijkstra could predict the future, in particular in a realm that somewhat exceeds the domain of his expertise. For example, I think by now we have a good understanding of the relevance and importance of software maintenance. Sure, software is not "subject to wear and tear", but the world around software evolves and a program that did a job well 10 years ago might not to the same job well today (think about security). We all understand this difference; i.e., I don't think his nit-picky attacks on software engineering metaphors are particularly useful from today's perspective.

ogogmad• 6 years ago

He was an advocate of formal methods like Hoare Logic, which in principle could be used to write highly secure programs.

It's possible though that not all aspects of security can be addressed by formal methods. There's the issue of side-channel attacks (like SPECTRE), which are not easy to model using formal methods.

UncleMeat2• 6 years ago

I think this is the difference between cs and software engineering. Two people can look at a problem (build secure programs). The cs person sees static analysis, model checking, and other mathematically principled approaches as the solution. The engineer sees a suite of human approaches (code review, testing, fuzzing, audits, etc). I think the pure cs vision is narrow and limits our ability to choose the best method to solve a problem for the minimal price. Formal methods should be like unit tests, a component of the software engineering process. But it should also be acceptable to acknowledge its role and limits, just like how we don’t rely exclusively on unit testing to deploy correct programs.

lapinot2• 6 years ago

It's possible though that not all aspects of security can be addressed by formal methods.

Well, one can always devise some well-defined model in which you can prove stuff. So nothing is ever unreachable.

There's the issue of side-channel attacks (like SPECTRE), which are not easy to model using formal methods.

SPECTRE is not an error in programs, it's a breach of contract of the CPU (what shouldn't be observable actually is). I'm pretty sure formal methods would be of great help to design clean interactions between a speculative engine and the cache hierarchy. See eg https://plv.csail.mit.edu/kami/ from umbrella project deepspec.

One very common side-channel at program level (and probably one of the most important) is timing side-channel (and all derived: power draw, noise level etc). This one is "easily" solved (in the sense it's not an open research question): have constant-time function types. It's not hard discriminating between what's constant time and what's not: don't branch on input and execute only constant time primitives.

andi9992• 6 years ago

I somehow do not understand what the article is really aiming at, but what I found interesting: " the subculture of the compulsive programmer, whose ethics prescribe that one silly idea and a month of frantic coding should suffice to make him a life-long millionaire" I am suprised that this was a thing in 1988. Can somebody enlighten me what this is refering to? (I mean nowadays it is obvious) but was there the software startup culture in th e 80s?

pjc50• 6 years ago

It certainly matches early Atari, and there were lots of microcomputer game developers in the 80s who managed it. They were smaller than startups - often just the single programmer and someone helping them duplicate casette tapes.

bonoboTP6• 6 years ago

There was a mini gold rush to write software for the new personal computers like the C64, including games and business programs.

carapace2• 6 years ago

You may have heard of Bill Gates? Steve Jobs? Larry Ellison? C'mon. :)

andi9992• 6 years ago

Yes, but this was more marathon then sprint, wasnt it?

hackerbabz• 6 years ago

If I wanted to learn formal verification methods like he describes, can anyone recommend where to start?

tomohawk• 6 years ago

Do the universities provide for society the intellectual leadership it needs or only thetraining it asks for?

How about both?

There is a necessary and sufficient course of study for someone to be successful - gainfully employed as a programmer using technologies of the day.

There is a different course of study that is necessary and sufficient to produce an academic.

Many other areas of study are similar. It is one thing to train someone to be a lawyer, quite another to train someone to be a law professor.

wdiamond• 6 years ago

Programming is magic based on science. Without actuators/mech engines it won't go anywhere, its just ilusion proven or not.It may be known as a light drug development.The focus is on transfering numbers. Money is another kind of ilusion, a kind that fakes demands. The focus is on increasing or decreasing numbers.

On the cruelty of really teaching computing science (1988) [pdf]

Related Stories