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