TITLE: A Blog Entry From Before I Had a Blog #2
AUTHOR: Eugene Wallingford
DATE: June 04, 2007 8:22 AM
[ UPDATE: I have corrected the quote of
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
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.
The Metaphor Metaphor, by Kent Beck
November 6, 2002
"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 trope is an expression whose meaning is not intended
to be derived from the literal interpretation of its words. There are
many kinds of trope:
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 is
and is not. How a metaphor holds and how it doesn't
both tell us something valuable.
Metaphors run deep in computing. An example: "This is a memory
cell containing a 1 or a 0." 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
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 +
A lot of good design is waiting productively.
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
about toggling the on/off switch of a hung computer to make it
Kent's final recommendations:
- irony: spoken such that the opposite is true
- paralipsis: speaking to a subject by saying that you won't
- hyperbole: excessive exaggeration
- pun: using word sounds to create ambiguity
- metonymy: refer to the whole by referring to a part or a role
- simile: explicit comparison
- analogy: simile with connections among the parts
- metaphor: the linkages plus the concomitant understanding that results
[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
- Be aware of computing's metaphors -- and your own!
- If the Grounding Hypothesis is correct,
then more physical activity makes better programmers.
(Or at least ones with more interesting things to talk about.)