2010/1/21 Raoul Duke <rao...@gmail.com>:
> 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)."



Reply via email to