A big teacher wish
Richard A. O'Keefe
ok at cs.otago.ac.nz
Fri Nov 29 01:39:01 UTC 2002
Stephan Rudlof <sr at evolgo.de> wrote:
[stuff that had me purring]
For me even #instanceVariableNames: in *meta* classes (accessible in the
class pane of a browser) are a concept, which is easy to understand: each
instance of the corresponding meta class (the class with its subclasses) has
its own class instance variable (which is then accessible like a class var
in all of *its* instances). This concept highly corresponds to the concept
of instance vars of instances of ordinary classes.
What is difficult to understand here?
1. First, there is an interface issue. Setting class variable names is
done in the "instance" pane; setting class instance variable names is
done in the "class" pane. If you don't already know what these
things are, it is far from obvious that
FooBar class
instanceVariableNames: ''
is talking about a third kind of variable. It is common for students
to think that it is an alternative interface for setting
class variable names.
2. Second, to get your head around this, you have to be good at thinking
a particular way. Just for now I'll call it "algebraic" thinking.
You have to be able to say to yourself, "what if I take this literally?
What if I try to apply the 'instanceVariableNames' concept to the
'metaclass' concept? OH, these things are like instance variables
but they belong to instances of the metaclass instead of instances
of the class."
Many people, as this thread has painfully demonstrated, DON'T think
that way. They think in a "verbal analogy" way. They are happy
using the same word for variables and the values of variables.
They talk about excluding ideas, and think that just excluding words
is sufficient to do this. THIS IS NOT A MATTER OF BETTER OR WORSE
THINKING. Each kind of thinking is effective in its own sphere.
A really good criminal lawyer, for example, will need to be very good
at both kinds of thinking: "algebraic" thinking to understand
expert witnesses, "verbal" thinking to understand others and influence
the jury. People are generally pretty imprecise in what they say,
leaving it to their (intelligent) hearer to figure out what they
really mean. When you see transcripts of actual speech, it's
horrifying. We're so good at figuring out at what people MEAN that
we don't pay much attention to what they SAY, as a rule. So this
kind of thinking works WITH people. It's highly persuasive, and it's
highly effective for dealing with the strange things people say.
This kind of thinking DOESN'T work with technology. If you try to
tell an electric light bulb that 240 volts is pretty much the same
as 110 volts, it's all volts, just a few more of them, it isn't
going to be persuaded. If you use the same word for a video cassette
as for a video cassette recorder, that doesn't alter the fact that one
of them plugs into a wall socket and the other doesn't.
So the thing that is difficult to understand here is that the
Squeak interface is using *technical* language *precisely*
and you should take it *literally*.
It's very important, of course, that Squeak is not about preserving
the status quo. Squeak is a work in progress. Just because Squeak
currently uses certain terms and interfaces doesn't mean that _anyone_
thinks those are the best terms or interfaces. I for one am drooling
at the thought of having Traits, and to use them the way you declare a
class will _have_ to change somehow.
One possibility, for example, would be to construct class declarations
by drawing pictures. UML diagrams are one possibility, although UML
doesn't really fit Smalltalk all that well. Perhaps one could find
a ClassMorph, ask it to make a new subclass, edit the name, drop
TraitsMorphs onto it, I don't know what. Perhaps you would create
a VariableMorph with a name box and a description box and drop that
onto a ClassMorph. I don't know. Maybe Connectors can become a browser.
More information about the Squeak-dev
mailing list
|