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
it.
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
|