TITLE: A Blog Entry From Before I Had a Blog #2
AUTHOR: Eugene Wallingford
DATE: June 04, 2007  8:22 AM
DESC: 
-----
BODY:

[ <STRONG>UPDATE</STRONG>: I have corrected the quote of
<A HREF="http://alistair.cockburn.us/index.php/Main_Page">
   Alistair Cockburn</A>
that leads below.  I'm sure Kent gave the right quote in
his talk, and my notes were in error.  The correct quote
makes more sense in context.  Thanks, Alistair. ]

Back in March 2006, I posted notes on an OOPSLA 2003
invited talk by
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-03.html#e2006-03-07T18_44_26.htm">
   David Ungar</A>.
While plowing through some old files last week, I found
notes from another old OOPSLA invited talk, this from
2002: Kent Beck's "The Metaphor Metaphor".  I've always
appreciated Kent's person-centered view of software
development, and I remember enjoying this talk.  These
notes are really a collection of snippets that deal with
how language matters in how we think about our projects.

<IMG SRC="http://www.cs.uni.edu/~wallingf/blog-images/misc/kent-beck.jpg"
     ALT="Kent Beck"
     ALIGN="right">

<H4> The Metaphor Metaphor, by Kent Beck </H4>

<I>November 6, 2002</I>

"Embellishment is the pitfall of the methodologist."  (Alistair Cockburn)

You gain experience.  You are asked for advice.  You give advice.  They
ask for more.  Eventually, you reach the end of your experience.  You
run out of advice to give.  But you don't run out of people asking you
for advice.  So, you reach...

Stupid ideas are important.  How else will you know that the clever ideas
are clever?  Don't be afraid of stupid ideas.

A <STRONG>trope</STRONG> is an expression whose meaning is not intended
to be derived from the literal interpretation of its words.  There are
many kinds of trope:
<UL>
<LI> irony: spoken such that the opposite is true
<LI> paralipsis: speaking to a subject by saying that you won't
<LI> hyperbole: excessive exaggeration
<LI> pun: using word sounds to create ambiguity
<LI> metonymy: refer to the whole by referring to a part or a role
<LI> simile: explicit comparison
<LI> analogy: simile with connections among the parts
<LI> metaphor: the linkages plus the concomitant understanding that results
</UL>

Think about how much of our communication is tropic.  Is this a sign that
our words and tools are insufficient for communication, or a sign that
communication is really hard?  (Kent thinks both.)

A key to the value of metaphor is the play between <STRONG>is</STRONG>
and <STRONG>is not</STRONG>.  How a metaphor holds and how it doesn't
both tell us something valuable.

Metaphors run deep in computing.  An example:  "This is a <U>memory</U>
<U>cell</U> <U>containing</U> <U>a 1 or a 0</U>."  All four underlined
phrases are metaphorical!

Kent's college roommate used to say, "Everything is an interpreter."

Some metaphors mislead.  "war on terrorism" is a bad metaphor.  "war
on disease (e.g., cancer)" is a bad metaphor.  Perhaps "terrorism is
a disease" is a better metaphor!?

Lakoff's Grounding Hypothesis states:  All metaphors ground in physical
reality and experience.  [Kent gave an example using arithmetic and
number lines, relating to an experiment with children, but my notes
are incomplete.]

We made Hot Draw "before there were computers".  This meant that doing
graphics "took forever".  Boy was that fun!  One cool thing about graphics
programming: your mistakes look so interesting!

Hot Draw's metaphors:  DRAWING +
<UL>
<LI> FIGURE
<LI> TOOL
<LI> HANDLE
</UL>

<STRONG>A lot of good design is waiting productively.</STRONG>

Regarding this quote, Kent told a story about duplicating code --
copy-and-paste with changes to two lines -- and not removing it.
That's completely different from copying and pasting code with
changes to two lines and not removing.  [This is, I think, a nod
to the old AI koan (listed first
<A HREF="http://www.lisp.org/humor/ai-koans.html">
   here</A>)
about toggling the on/off switch of a hung computer to make it
work...]

Kent's final recommendations:
<UL>
<LI> Be aware of computing's metaphors -- and your own!
<LI> If the Grounding Hypothesis is correct,
     then more physical activity makes better programmers.
     (Or at least ones with more interesting things to talk about.)
</UL>

[end of excerpt]

That last recommendation reflects a truth that people often
forget:  Well-rounded people bring all sorts of positives,
obvious and less so, to programming.  And I love the quote
about design as "productive waiting".

As with any of my conference reports, the ideas presented belong
to Kent unless stated otherwise, but any mistakes are mine.  With
a five-year-old memory of the talk, mistakes in the details are
probably unavoidable...
-----