Smalltalk on the small end (was: Advice requested: GUI project beginning)

Christopher Browne cbbrowne at news.hex.net
Mon Apr 3 20:41:08 EDT 2000


Centuries ago, Nostradamus foresaw a time when Cameron Laird would say:
>In article <m12b4OW-000wcEC at swing.co.at>,
>Christian Tanzer <tanzer at swing.co.at> wrote:
>			.
>			.
>			.
>>Recently, I find myself writing Python scripts of 5 to 20 lines for
>>which I normally would have used the unix shell. I wouldn't use
>>Smalltalk for this purpose.
>But others do (particularly with GNU Smalltalk),
>so this isn't conclusive.
>
>Actually, there's another thread here asking to
>be launched.  Python (and Tcl, too, in a somewhat
>different fashion is (are) really quite extraor-
>dinary for shell-level scripting and operation.
>I find myself wondering more and more how people
>get along without such (*particularly* on the
>conventional desktops--Win* and MacOS).  I do
>think Python is clearly superior to Smalltalk
>for those one-page scripts that most people do
>with /bin/sh; still, I'm willing to consider that
>Smalltalk is more capable in this regard than I
>yet realize, and, in any case, I can well imagine
>Smalltalk proponents favoring it over /bin/sh.

The "power" of Smalltalk comes not when you're writing one page shell
scripts, but when you have a bunch of "objects that do useful things"
that can all run in a single Smalltalk environment.

The point is that there's little point to "scripting" in Smalltalk
when it doesn't really get powerful 'til you build up a rich set of
functionality in a "Smalltalk Environment."  And *that* is something
you don't want to respawn repeatedly...

Similar could be said about scripting in Common Lisp.  There are CL
implementations (notably CLISP) that can load fairly quickly, but the
merits of writing script-like applications in CL would come not in
having a bunch of little scripts invoked via
   #!/usr/bin/clisp
but rather by building a somewhat larger environment that expresses
those "little scripts" as Lisp functions that can all run within a
single CL instance.

The same is probably also true for attempts to build applications in
Java; you don't want to keep spawning more JVMs, but rather to invoke
a bunch of applications from within the same one.
-- 
Developmental Psychology
"Schoolyard behavior resembles adult primate behavior because "Ontogeny
Recapitulates Phylogeny" doesn't stop at birth."
-- Mark Miller
cbbrowne at hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>



More information about the Python-list mailing list