A Lisper asks, "Am I supposed to like Smalltalk?"

Mitchell L Model MLMLists at Comcast.net
Fri May 19 16:19:23 UTC 2006

I've used Smalltalk extensively for 20 years, after 10 earlier years 
where I used it sporadically.  I was introduced to Smalltalk as a 
graduate student doing my research at Xerox PARC 1975-78.  My main 
language in those days was Interlisp, and I was the first user of 
Interlisp-D -- it's display version -- as Warren Teitelman developed 

When I returned East I worked in both Interlisp-D and Symbolics Lisp 
Machine Lisp.  The paradigm of the former is like Smalltalk's: edit 
in the image then, for secondary purpoes, occasionally file out to 
text (or to a code repository such as ENVY).  (It is no accident that 
Interlisp-D was developed in the same time and place as Smalltalk.) 
The paradigm of the latter was the usual edit an external textual 
representation and occasionally load the file into the image.  So, 
the distinction between the two approaches is not actually between 
Smalltalk and other languages (Lisp or Java or C++), but rather the 
working style encouraged (better supported) by the development 
environment.  You can work in either style in either kind of 
environment -- you can edit a fileout and file it back in in 
Smalltalk or Interlisp-D, and you can edit and redefine individual 
functions in Emacs and other file-based environments.  In fact, there 
is a <http://www.gnu.org/software/smalltalk/smalltalk.html>GNU 
implementation of Smalltalk that is independent of any development 
environment.  (By the way, it has some very intriguing features for 
interacting with the external modern world -- I recommend that ou 
take a quick look at the 
<http://www.gnu.org/software/smalltalk/gst-manual/gst.html>Table of 
Contents of the GNU Smalltalk User's Guide to get an idea of what 
this is all about.)

I came to refer to this distinction as West Coast vs. East Coast 
style. I discovered a similar distinctions in Continental approaches 
to software development -- Algol/Pascal/Modula, Simula, Prolog, etc., 
and a rigorous mathematical style of software construction that 
rarely said anything at all about development environments. I have 
encountered fundamentally different Continental, East Coast, and West 
Coast styles  in many things I've been involved in, even recreational 
activities.  For instance, in the days of wood tennis racquets there 
were even three  grips called, yes, Continental, Eastern, and 
Western.  Bidding systems in Bridge exhibit a similar division.  And 
so on. There are, of course, many facets of this, and these are 
extremes in a space of possibilities in which specific approaches are 
located, but very loosely speaking I would categorize Continental as 
abstract, Eastern as technological, and Western as cognitive, terms 
which correspond to broad sociological stereotypes in many ways.

  These approaches affect a lot more than the development environment, 
but though that is where their differences are most obvious.  (The 
effects of the differences often extend to applications GUI 
developers tend to provide their users with interfaces that are a lot 
like those in their development environment, in part -- to be fair -- 
because it is easier to reuse the various frameworks and components 
used for the development environment than to build something from 
scratch or using an external GUI package.)  There are many profound 
differences in between, for instance, Interlisp-D's tools and those 
in Lisp Machine Lisp, most having to do with the theme of lots of 
windows with easily accessible menu actions vs. relatively few 
windows with elaborate menu structures.  (Typically a Lisp Machine 
user would have one Emacs window open in which to do all editing, one 
File Browser, etc.)  I remember hearing many jeers from Lisp Machine 
folks about all the stupid support facilities in Interlisp -- things 
like spelling correction and history list -- coming largely from the 
macho real-hackers-don't-use-tools attitude, revealed by comments 
such as "By the time the DWIM facility figures out an alternative, 
asks me to confirm it, and waits for my response, I could have just 
retyped the input myself.".

For the past 20+ years I have been teaching, mentoring, and providing 
technical support to students and developers in object technologies 
(among other activities). As someone who came to technical maturity 
in Interlisp-D and Smalltalk -- West Coast software development -- 
but ended up working with students and developers accustomed to more 
traditional East Coast approaches to software development it took me 
a very long time to get past an arrogant disbelief that people just 
didn't see the Light when introduced to the fabulous new world of 
West Coast tool-based software development, as embodied in 
Interlisp-D and Smalltalk.

I have also worked extensively in Pascal, C, C++, Objective-C, Java, 
Perl, Python, JavaScript (which actually is a very cool 
instance-based object-oriented language much like self),  and 
undoubtedly a few I'm forgetting at the moment.  I have used 
different implementations of Lisp and Smalltalk and their development 
environments.  I have worked on just about every kind of platform, 
except for embedded systems: card-punch batch mainframes, teletype 
and glass-tty timesharing systems, intelligent terminals on Unix 
systems, Lisp workstations, Unix workstations, Macs (which are 
currently the best Unix machines around, by the way), and even 
Windows (when I absolutely can't avoid it). I have worked with a wide 
variety of development environments, and I even still use Emacs 
extensively.  I have gleaned ideas, tricks, techniques, inspiration, 
etc. from all of these.  Much of my arrogance has been tempered by 
all this cross-cultural travel -- it has morphed into condescension 
;-) .

I believe I have acquired a deep understanding of many social, 
psychological, and cognitive factors that cause people to resist 
change in general and to feel more comfortable with the more concrete 
nature of text files even though they work less efficiently and 
creatively than is possible in more "enlightened" environments.  Some 
people I work with still use vi instead of Emacs, which in some ways 
is a similar difference.  This all gets very, very complicated.  It 
is affected by institutional requirements (as some have pointed out 
in this thread), by shared technological cultures, by substantial 
variations in personality and cognitive stle, and (as has also been 
discussed in this thread) how we teach people about the wonderful New 
World to which we migrated (or for those less encrusted with age than 
I, perhaps even born in!).

I still grumble, rant, and rave when working outside of Lisp, 
Smalltalk, or Python (which is really Smalltalk with a different, and 
cognitively effective, syntax -- try it, you'll love it -- it's to 
Perl what Smalltalk is to C++).  I'm still frustrated with more 
mundane development environments.  I am still astounded at the 
obtuseness and resistance of all the techie types I work with. 
However, I long ago came to terms with the less enlightened, people, 
languages, and environments -- I pretty much just write Lisp or 
Smalltalk style code no matter what procedural language I'm working 
in ;-).

(I'm certainly not alone in my insistence on a Lisp/Smalltalk/Python 
style of development and coding.  Perhaps the most extreme example 
I've encountered was a project I consulted to at an enormous 
Boston-based financial institution.  It was developing a very cool 
workstation-based trading system in Smalltalk when the company 
decided to standardize on C++.  Told that they couldn't deliver a 
Smalltalk application, they just shrugged and a compiler wizard who 
happened to be working on the project wrote a C++ code generator that 
processed their Smalltalk code, while they continued to happily work 
in VisualWorks.)

I also spend a lot of time extending and customizing environments 
(especially Emacs) that don't provide the facilities I require. 
(Emacs isn't too bad because it is so strongly Lisp oriented in both 
its implementation and its tools, and it is so entirely flexible 
given its Lisp extension language and rich array of programmable 
functionality.)  Of course given a choice I'd still rather work in 
Smalltalk, Lisp, or Python.  (There is <http://www.wingware.com/>an 
excellent development environment for Python that I am happy using.) 
And I have hopes that rapidly multiplying and evolving Open Source 
development tools and environments for traditional languages (which I 
mean to include C++ and Java) will ultimately provide their users 
with something very much like the Smalltalk development environment.

Incidentally, the distinction between source code edited in the image 
and source code edited externally is a lot like that of the so-called 
"compiled" vs. "interpreted" language distinction.  Languages by 
themselves are neither compiled nor interpreted.  Instead, it is a 
question of environment -- are you working with a compiler that 
forces you to into a coarse-grained edit-compile-execute cycle or are 
you working with an interpreter that allows you not only to make 
fine-grained changes that take effect immediately -- even within 
executing code -- but also to enter and execute arbitrary bits of 
code.  (And what exactly are you doing inside an interactive debugger 
in a traditional sort of environment in which programs are externally 
executed then compiled and loaded?) Besides, the byte-code world that 
Smalltalk popularized has made that distinction moot.  Witness Java 
and Python or, more interestingly, Jython which is a Java engine 
implementation of Python that allows Java code to call Python code 
and vice versa.

So there.  I started this as a quick note to point out from my 
unusually long and cross-cultural perspective and especially from my 
extensive experience with multiple Lisp environments I can see that 
the issue of internal vs. external source code editing is not one of 
language but of development environment.  But this is all entangled 
in so many other related aspects of the difference between what we do 
in Smalltalk and what people do in traditional environments that I 
found I couldn't just leave it at that.  I hope you found this worth 
slogging through.  I particularly hope you find it useful in 
explaining our world to both Lispers and traditionalists.
         Mitchell L Model, Ph.D.        MLM Consulting
         mlm at acm.org                    42 Oxbow Road
         (508) 358-805                  Wayland, MA 01778

         ~~ Mentoring, training, & tool building for
            object, knowledge, & web technologies
         ~~ Representation, processing, and display of
            complex information & knowledge, esp. scientific
         ~~ Interface design, usability evaluation, &
            productivity enhancement
         ~~ Commited to effective agile software development
         ~~ Specializing in bioinformatics, web technologies,
            knowledge representation/management, and ontologies
         ~~ Expert in object-oriented design, programming, &
            languages (Lisp, Smalltalk, Python, Java, C++, etc.)
         ~~ Experienced in distributed architectures
            (CORBA, Zope, J2EE, OODBs, socket-based, etc.)
         ~~ Collaboration methods and technologies (Wiki uses &
            customizations, eXtreme Programming, IDE's, etc.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20060519/ac845a48/attachment.htm

More information about the Squeak-dev mailing list