<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: A Lisper asks, "Am I supposed to like
Smalltalk?"</title></head><body>
<div>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. </div>
<div><br></div>
<div>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,<b> the distinction between the two
approaches is not actually between Smalltalk and other languages</b>
(Lisp or Java or C++),<b> but rather the working style encouraged</b>
(better supported)<b> by the development environment.</b> 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 <a
href="http://www.gnu.org/software/smalltalk/smalltalk.html">GNU
implementation of Smalltalk</a> that is independent of<i> any</i>
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 <a
href="http://www.gnu.org/software/smalltalk/gst-manual/gst.html">Table
of Contents of the GNU Smalltalk User's Guide</a> to get an idea of
what this is all about.)</div>
<div><br></div>
<div>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<b> I would categorize Continental as abstract,
Eastern as technological, and Western as cognitive</b>, terms which
correspond to broad sociological stereotypes in many ways.</div>
<div><br></div>
<div> 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.".</div>
<div><br></div>
<div>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. </div>
<div><br></div>
<div>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 ;-) .
</div>
<div><br></div>
<div>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!).</div>
<div><br></div>
<div>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> I pretty much just write Lisp or
Smalltalk style code no matter what procedural language I'm working
in</i> ;-).</div>
<div><br></div>
<div>(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.)</div>
<div><br></div>
<div>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 <a
href="http://www.wingware.com/">an excellent development
environment</a> 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.</div>
<div><br></div>
<div>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. <b> Languages by themselves are neither compiled nor
interpreted. Instead, it is a question of environment</b> -- 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.</div>
<div><br></div>
<div>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.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><font face="Andale Mono" size="-1"
color="#000000"> Mitchell L
Model, Ph.D. MLM
Consulting<br>
mlm@acm.org <span
></span>
42 Oxbow Road<br>
(508)
358-805 <span
></span> Wayland, MA
01778<br>
<br>
~~ Mentoring, training, &
tool building for</font></div>
<div><font face="Andale Mono" size="-1"
color="#000000"
> object,
knowledge, & web technologies<br>
~~ Representation,
processing, and display of<br>
complex
information & knowledge, esp. scientific<br>
~~ Interface design,
usability evaluation, &<br>
productivity enhancement<br>
~~ Commited to effective
agile software development<br>
~~ Specializing in
bioinformatics, web technologies,</font></div>
<div><font face="Andale Mono" size="-1"
color="#000000"
>
knowledge representation/management, and ontologies<br>
~~ Expert in
object-oriented design, programming, &<br>
languages
(Lisp, Smalltalk, Python, Java, C++, etc.)<br>
~~ Experienced in
distributed architectures<br>
(CORBA,
Zope, J2EE, OODBs, socket-based, etc.)<br>
~~ Collaboration methods
and technologies (Wiki uses &<br>
customizations, eXtreme Programming, IDE's, etc.)</font><br>
<font face="Andale Mono" size="-1" color="#000000"></font></div>
</body>
</html>