Laurence Rozier wrote:
> Indeed - the power of the Smalltalk meme
<http://croquet.funkencode.com/2007/04/07/evolution-in-cyberspace-the-smalltalk-meme/>!

Wow, that link just chewed up a couple hours for me strolling down Smalltalk
memory lane, following more links from stuff on that blog. Yours? :-)
    http://squeak.funkencode.com/intro/   (No name?)
    http://croquet.funkencode.com/2006/04/18/about/ (Your name)

Those comments on the history of Smalltalk around 1996 or so prompted to
Google up this old thing I wrote to the Squeak list in 1998, and now have to
say I was ultimately somewhat wrong about what I wrote back then: :-)
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-April/021255.html
"The major weaknesses I see with Squeak right now are speed (that of a
Java applet in some browsers, 1/40C (1/20 with Jitter?)), the lack of
standard GUI components (like comboboxes), lack of standard exception
handling, and lack of local block variables (not shared in the method).
People are working on all those issues, and I have more confidence those
will be improved or that speed won't matter as computers get faster,
than I do that Java will ever become an open standard with the features
I want (which Smalltalk has right now, like first class objects
everywhere)."

And here I am, ten years later, advocating Squeak on the JVM, now that the
JVM is free, more full featured, and more debugged. :-) It even has objects
everywhere if you pick another JVM language like Scala or Clojure. (Though I
still don't like Java very much, even as statically typed languages go. :-)
I think most of those Squeak issues got fixed, too (except maybe speed).
Though Squeak also acquired some new issues related to complexity currently
being worked through. So, in some ways, we now have the best of both worlds. :-)

And in reading various related entries to why Smalltalk failed to expand
with the internet bubble:
  http://squeak.funkencode.com/category/community/
especially:
http://squeak.funkencode.com/2008/01/29/smalltalk-reloaded-missing-bits-the-achilles-heel/
I think a Smalltalk which can easily interoperate with JVM libraries might
solve some of those problems, just like Jython gets extra leverage by being
able to use Java libraries for sockets and threads and graphics and network
APIs such). Suddenly (in theory), as with Jython, Squeak could do everything
Java could do -- write PDFs, manipulate SVG, talk via Jabber, simulate
molecules, and so on. Most of the time woudl be an effort spent mostly
reading the APIs and translating the concepts, which sometimes has proved
not-quite-straightforward, even for syntactically similar Jython, at least
at first. I know, Squeak can probably do all those things already, and more,
but I'm sure if I looked hard I'd find things it could not. :-) Also, I know
it loses some of the transparency Squeak has. :-(

The Lively Kernel (Dan Ingall's latest project) is described in the latest
blog entry there as a "Squeak on JavaScript". So that is in a sense another
example of the Smalltalk meme spreading to another language (though with a
little help from one of the original creators. :-)

From:
  http://squeak.funkencode.com/2008/02/08/lessons-from-the-lively-kernel/
"Dan Ingalls did a Google Tech Talk last month which may be of interest to
many of the current Squeak-dev list discussions(Morphic 3, JVM etc.) as well
as Croquet or anyone interested in the web as distributed object space."

I watched the video at:
  "The Lively Kernel"
  http://www.youtube.com/watch?v=gGw09RZjQf8

Some notes by me:

Issues raised as important to add or expand by Googlers included:
* Security (Programmer vs. User, development vs. deployment/use)
* Complexity ("attenuate affordances", expert vs. beginner, HyperCard)
* Versioning (Squeak has, Lively does not yet)
* Annotations (Semantic markup of drag and drop actions would be nice)
* Serialization options (a textual image vs. SVG?)
* Transformation (export to HTML)
* Factoring (GUI Libraries vs. Native vs. complexity of an extra layer)
* Is "test driven" is becoming a dogma for everything, as valuable as it can
be? :-)

A lot of these issues apply to Squeak as well and have been discussed here
at one time or another. :-)

There were a lot of sharp people asking good questions, but still, it seems
to me like some of these Googlers didn't come across as understanding
"having fun" or "exploration" or "R&D", as in "What good is a new baby?"
(Edison? Tesla? :-) You'd never get quite that same attitude in, say, a
colloquium in a university department of mathematics after a seminar on a
new and elegant approach, to, say, esoteric-seeming knot theory:
  http://en.wikipedia.org/wiki/Knot_theory
"In the last several decades of the 20th century, scientists and
mathematicians began finding applications of knot theory to problems in
biology and chemistry."

Also, just because a system with X doesn't have Y or Z yet (or ever), does
not mean X is not awesome by itself. :-) So I agree with this comment:
http://javascript.funkencode.com/2008/02/08/lively-kernel-google-tech-talks/
"So many people seem to miss the simple albeit very subtle value of a clean
architecture."

I was surprised (for Google) no one raised "scaling" issues about any
obvious size/performance limits.  Also, there is an issue of when is a web
page live so it can receive input or serve output to other than the
immediate viewer? It was implied the same code could run on a server.

Lively Kernel does seem like Squeak done even more simply and clearly,
including a clearly "open source" license (GPL v2). The success shows syntax
does not matter as much as dynamic semantics.

So the overall architecture could be a great starting point for anything in
Smalltalk (respecting the GPL license if one borrows from it in a derivative
way) for a "blue plane" future Squeak.
http://www.fit.vutbr.cz/study/courses/OMP/public/software/sqcdrom2/Documents/WhereIsSqueakHeaded1998.html
[although for me, the "blue plane" seems now to have to do more with
leveraging the creative work of others entombed in static Java libraries,
maybe even at the cost of losing a bit of what Squeak has now. :-( ]

I did a little of the same idea (though not such a tour de force) with
Python and Jython in the PataPata experiment (inspired by Squeak and Self).
A video of it in use:
  http://showmedo.com/videos/video?name=patapata_tkinter1_fSchnell
The place where Python and Jython fell over (compared to Smalltalk) was
coding in the debugger. Python just was not designed that way -- even though
you would think it would be a trivial thing for such an otherwise dynamic
language (more dynamic in some ways than Smalltalk, since instance variable
data is stored in dictionaries, not array slots), but it looks like it is
not easy to patch that kind of comprehensive support for restartable
exceptions in after-the-fact. But I'm wondering if JavaScript is up to
coding in the debugger either? Dan said Lively was doing something with a
shadow stack wrapping each function call, so maybe it can? Even if you
can't, as with Python and Jython, you can still change code on the fly (Dan
showed an example with the clock), which in practice sometimes works out OK
for coding GUIs since you can often just abandon an exception and retry the
GUI action with the changed code. But it doesn't work out so well if you've
just run an hour long non-GUI simulation and a typo pops up an exception,
and you need to rerun the whole thing to make one change.

Lively was slow for me where I tried it (iBook G4, Safari 3.0). Runs with
problems on latest Debian stable IceWeasel (FireFox) -- but that browser
version is not a current target. Not obvious how to activate menus or get
handles, which was my biggest difficulty with it.

Bottom line issue for me and this thread: Lively Kernel is not quite as much
a system-in-itself compared to Squeak (but that is not intended by me as a
complaint. :-) It almost certainly uses non-JavaScript compiled libraries
for SVG, XML parsing, JavaScript parsing, networking, and presumably others
supplied by the browser. So that is why it is only 10K lines of code
(guessing 300K?), compared to minimal Squeak on the JVM Dan put up a link
for of about 900K (or three times the size). The Squeak version also does
less in some ways because it is a MVC version (not Morphic). So, basically,
this all might imply a good enough Smalltalk core on the JVM to be
interesting, calling on the Java libraries for graphics and other
functionality, should also be roughly about 10K lines, or about 120 pages of
core code (maybe a little more to add a Smalltalk Compiler, but not much).
But that is just an assessment without looking at the code; perhaps Lively
does more of the low-level graphics manipulation (like matrix
transformations) in JavaScript than I guess it does. In any case, Lively
Kernel is, for me, a good proof-of-concept of what a Squeak core on the JVM
might look and feel like in terms of code complexity.

For my various plans, I still prefer to have a a Java application
(webstarted perhaps, and maybe also an applet) for these reasons:
  http://mail.python.org/pipermail/edu-sig/2006-July/006683.html
(See the section on "sovereign" versus "transient" appreciations.)
But I don't really have a good feel yet for all the the potential uses of
Lively Kernel; for example, I read somewhere the latest Java runtime
integrate JavaScript, so presumably a version of Lively as is could run
easily as a Java application (and be faster?), and so also potentially
interoperate with Java code. I also just really haven't thought much about
that whole Web URL space it occupies from a "transient" perspective.

Java right now probably has a much bigger potential audience than Safari
3.0. Although maybe not if you consider how much trouble many people have
(even me sometimes) just finding where they put downloaded software, let
alone actually installing it. :-) Java in the future would seem to be a
smaller audience than all JavaScript-enabled web browsers as people continue
to upgrade over the next few years. I might expect all browsers to have
JavaScript accessible, but only some to have Java enabled. I have a relative
who is a school teacher who was forced to sign a document acknowledging that
she could be fired for installing any software on her classroom computers.
So Lively really does address a very important problem I know of -- although
often Java is enabled on classroom computers too. :-) Either way, Sun wins
-- Java or Lively. A nice way to hedge its bets. :-) And Dan and company
have really pushed the envelope once again -- this time in installation
convenience as well as elegant design.

But of course I would want all the Lively ideas in a JVM version of Squeak
(as well as ponder how or whether to address the list of extra requirements
the Googlers came up with). I loved the Lively style browser modifying the
style browser; PataPata inspectors could do that too (though not as sleekly.
:-) And I really loved the rotating star on a rotating star. There must be a
lot of great abstractions at work there under the hood for 10K lines of code
(whether Morphic-derived or otherwise).

By the way, I should have added that every one of the 200 or so JVM
languages listed here:
  http://www.robert-tolksdorf.de/vmlanguages.html
are in some sense a tribute to Dan Ingalls and others who developed the
original Smalltalk VM. Each is a tribute to the notion that the idea of an
OO VM with GC and meta-reflectivity makes it easier for people to be more
creative. :-) Even JavaScript itself (used in Lively) is a tribute to the
Smalltalk philosophy in many ways.

--Paul Fernhout