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 []

Reply via email to