Thinking about a better UI
Andrew C. Greenberg
werdna at gate.net
Sat May 15 14:42:41 UTC 1999
>This was one of my initial grudges against Smalltalk: Lots of new words
>meaning just the same old stuff
.. . .
>I concede there are important differences, and a different set of
>concepts.
A crticial concession: Important differences and different concepts.
This is *why* its a good idea to use different words.
Messaging is a different concept from a "subroutine call with special
first parameter." Trying to think about oo programming in simple
imperative concepts is one of the things that kept me from "getting
it" with oodls initially, because I was always thinking about these
things constructs by their analogues.
In general, a programming language concept *is* a thing which is
different from the various ways it might be implemented in another
programming language. I can think of monitors and CSS as an
implementation of semaphores and streams as well, but to do so simply
misses the point.
Besides, there's nothing special about subroutines either.
Subroutines are just a couple of pushes onto a stack, a save of an
instruction pointer, and a naked jump to some other code. And a
while loop is just a special case of a goto. Why don't we just go
back to coding purely with stores, loads, tests, logical ops and
jumps? Aren't they all just the same thing?
And heck, every programming language concept is just an
implementation of a state machine with a read/write movable head and
a very large tape. Why don't we just express programming concepts in
terms of Turing machine programming techniques?
All meaningful programming languages are capable of expressing any
computable function. This doesn't mean that all programming language
concepts are "just the same thing."
Correspondence between those languages, in the sense that one might
be implemented in another, isn't necessarily a useful observation,
even if true. But more important, expecting a new programming
language to be capable of expressing a program that another one
cannot is unreasonable -- at least theoretically speaking, they're
all just flawed implementations of a Turing machine, capable of
generating the same set of programs.
Although one might attempt to reason about Smalltalk code by way of
these analogues, I think it is losing to try to learn Smalltalk in
this fashion, at least once you have gotten past the syntax and basic
semantics stage. Once I recognized that these *were* a different set
of concepts with important differences, and started to think about
them independently of the various possible ways to implement them, I
found myself empowered in a way that surprised me.
[Mind you, I had the Smalltalk books on my Shelf since I bought them
at graduate school in the early 80's -- I, too, simply looked at the
books, tried to figure out how it was like Pascal, Algol, C and Lisp,
and shelved it as "nothing new." Almost two decades later, after a
fair amount of experience programming in OODLs, I found Squeak and
ultimately learned something, I think, in part BECAUSE of the new
nomenclature.
Edsger Dijkstra wasn't the first to note, although he was a principal
exponent of the notion, that a notation and language colors and
impacts the quality of our ability to conceive and implement
solutions, and hence, the scope and quality of programs we are
capable of creating given a fixed amount of programmer effort.
Coding Smalltalk by thinking about it as C with some tweaks leads to
frustration, not with the words, but with the mismataches between
concepts. Coding Smalltalk qua Smalltalk is another thing entirely.
Agreed, the words are distracting at first, but like all techniques
learned, they are quickly absorbed once you set out to learn them,
and rapidly become second nature. Interestingly, as I found myself
misusing the words in different ways initially, I learned that I was
likewise misunderstanding the concepts. Nomenclature is a VERY
useful thing. Agreed, I can code up Smalltalk methods in C,
modelling them as subroutines. But I no longer think of them in this
way, and found Squeak a much nicer place to play once I did.
More information about the Squeak-dev
mailing list
|