2010/1/21 Raoul Duke <[email protected]>: > if i skimmed + parsed the paper correctly, it seems like the message > is: this is how people talk about programming, and thus we should make > our programming systems support those forms of thinking. but i have an > alternate hypothesis: given how bad people claim software ends up > being, perhaps the paper is showing us what forms of thinking re: > programming to avoid. which would then lead to the question of what > thinking should be used instead? vaguely like the issue between > s1/intuition vs. s2/formal thinking.
Well I think Dijkstra would see most of these metaphors as betraying anthropomorphism and therefore operational thinking. I think he's right there, although don't think that's necessarily bad (he does). I think unless a programmer is writing something like a control system for aeroplanes, they should use their imagination, and that human imaginations are necessarily grounded in human bodies. Dijkstra has something nice to say about metaphor and programming errors: "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, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error)." http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html alex -- http://yaxu.org/
