Derek M Jones wrote:
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
Some of the forms of thinking to avoid includes:
o getting the requirement right (a lot of software is 'bad'
because it was designed to do something other than what it is
being used for), alternatively use tool/software that is designed
to do the job at hand
o employing low quality developers (this form of
quality is always hard to measure)
o patching software far beyond what is was designed to do
Sorry, but I don't see how any of those count as forms of thinking.
Surely they are, roughly, and in order: a methodological approach;
a policy; and the (possibly unintended) outcome of a series of actions.
Where are choices of programming metaphor involved in any of those?
Frank Wales [fr...@limov.com]