Hi Shane and all!

Just wanted to chip in a few remarks here and there.

shane at shaneroberts.com wrote:
> Since becoming re-interested in Smalltalk (after 20 years) a few
> days ago, I keep running across references to "closures", "block
> closures",  and "block closures in modern Smalltalk".  Can anyone
> point me to information explaining these terms/issues?

Someone else will have to do that, I don't have any handy - and honestly
I don't know much about closures and continuations anyway...

Note that today we don't have proper closures in Squeak - at least not
in the current official release. Anthony Hannan has implemented it
though and it will appear soon. For anyone impatient enough there are
special Anthony-images/VMs etc to download, check the Swiki for more
info.

> Also, for years in the 80s and early 90s, any references I read
> regarding Smalltalk stated that it was too inefficient and not useful
> for practical applications.  I once flew to Los Angeles where I had

This has been false for at least 9 years :-) - I started using VW around
1994 to build "real" applications and it was really good/fast/other nice
superlatives.

> an appointment to evaluate a Xerox Dolphin workstation running
> Smalltalk.  This was about 1983, and I believe the Dolphin was
> priced at upwards of $100,00.00.  I requested a small example of
> Smalltalk programming.  The representative was tentative about
> what sort of example to show me, so I said, "How about a simple
> loop that prints numbers from 1 to 1000."  So a loop was written
> and executed.  It never got to 1000, it was TOO SLOW!  That
> about cinched it for me.

Heh, funny enough that snippet probably used the Transcript which in
turn needs to manage a buffer of contents and to scroll the output,
which in turn exercises the BitBlt of the Smalltalk in question and the
primitives for updating the display (damage recording etc) etc. In short
- Transcript is really dumb and slow and you have no buffering at all.

Time millisecondsToRun: [
	1 to: 100 do: [:i | Transcript show: i printString; cr]
]

With a medium sized partially covered Transcript window this took 5
seconds on my laptop! Whua! But wait...

Time millisecondsToRun: [
	Transcript show: (String streamContents: [:stream |
		1 to: 100 do: [:i | stream nextPutAll: i printString; cr]])
]

This version that produces the same end result takes 89 milliseconds to
run. And if we remove the printing on Transcript it takes about 2-5
milliseconds. Lesson to learn? Always profile. Transcript simply sucks.
Don't do benchmarks that prints on Transcript without taking that into
account.

> I also studied the Smalltalk implementation details published at that
> time (Addisson-Wesley whatever), actually I got pre-publication
> editions of the book for some reason.  I found it fascinating but felt
> there were to many layers to the message processing (inheritance
> hierarchy), for the system to perform efficiently enough.  The other
> thing that always bugged me was the "image".  It all seemed so
> tightly coupled, I couldn't figure out  how you would "share
> programs" or separate out "data files."
> 
> I'm sure this is all ancient history to those on the list.  These issues
> have long been debated and put to rest, but it is amusing reading
> about "how modules should work" after all this time.  My first
> impression about the image file was apparently on target, since it is
> still biting your ass after all these years.

Well, the image is in fact simply wonderful - a world of objects that
interact with each other with full dynamics. But of course the freedom
and dynamics of an image makes modules etc much more complicated. But as
a Smalltalker I would never give up the image just to get "nice
modules".

It would be like moving from a large very nicely planned 10-room villa
to live in 10 small 1-room cottages just because the carpenter couldn't
figure out how to build walls...

I say - we just need to figure out some more about wall-building. I will
never give up my villa.

> Anyway, all this aside, I ran Croquet today, which kept crashing.
> Apparently the network collaboration connection software isn't
> working for Windows yet.  But I was able to run all the built in

Well, my impression is that Croquet is highly dependent on what kind of
graphics hardware/drivers you have. My laptop kept crashing it (weird
graphics card or simply bad opengl driver - don't know) but other
hardware has been running the exact same version almost flawlessly.

> "toys", that are from Squeak.  So I did an experiment.  I ran
> everything I could in the Morphic world, all at once.  Spinning 3D
> block, ant hill, termites, chess, crawling blob, music synthesizer,
> clock, and mp3 player playing a symphony.  It all worked
> amazingly.  No crashing, skipping, wobbling.  The frame rate
> dropped to 50 ms, but everything continued to work impressively.  I
> let it run for hours.
> 
> I was mightily moved.
> 
> I have also done the basic programming tutorials.  The first tutorial
> I did I think locked up my image.  The tutorial said "pick any
> category, like Kernel-Object" for example.  So I did but when I
> wrote "Hello World" my image went into never never land.

Well, probably just looping - try "Alt-." which is the equivalent of
ctrl-c.

[SNIP]
> So we'll see if I can commit to Squeak and get serious with it...

Please do - you will not be disappointed.

regards, Göran