[self-interest] Self vs. Squeak

[Jecel Assumpcao Jr]

On Wednesday 23 June 2004 20:59, Michael Latta wrote:
> 1) I like the Self language better, if it only had full blocks.  But,
> both are far better than Java or C++!!!

As you mentioned in your other email, object literals can often be used 
in place of non-LIFO blocks. Given that the main use for these is to 
parameterize behavior in some variation of the Strategy Pattern, my 
experience is that using actual objects which can have more than one 
method is an improvement.

But I agree that it would be better not to have this implementation 
restriction (nothing in the language itself requires it).

See page 9 of http://www.merlintec.com/vmworkshop99/sub.pdf

> 2) Squeak has a much more active community that can provide
> support/help/ideas.

I had to decide between Self and Squeak for my project in 1997, and this 
was the major issue for me. The social aspect tend to dominate over the 
technical ones.

But I needed some non trivial changes and saw that the community could 
also be a problem in that a large portion of it was very conservative. 
There are several subgroups with very different goals. The SqueakLand 
people interested in stuff for schools (eToys, StarSqueak and so on). 
Traditional Smalltalkers who would like ANSI compatibility and native 
widgets. The web people (mostly servers and swiki).

While there was a "Squeak Central", radical changes were possible but 
very hard to get into the official Squeak. Now I would say it is just 
impossible. But if Squeak is already exactly as you need it, then this 
is not an issue.

> 3) Squeak is far larger in terms of libraries.

Right, though the opposite was true in 1997.

> 4) Squeak runs on Windows ( an advantage for comercial projects ).

There is a Windows port for Self (the Linux port+Cywin), but I have 
never tested it. Even if it doesn't quite work, I imagine it wouldn't 
be too hard to fix it. And you would have multiple native windows ;-)

And here we come to an issue you didn't mention - licenses. The Mac and 
Sparc Selfs have a simple, BSD-like license. The Linux and Windows 
ports are GPLed, which might be fatal for your project. The Squeak 
license gives rise to a bi-annual moby thread in the mailing list since 
Debian and the Open Source Initiative don't accept it. As Alan Kay 
always points out, nothing you do can prevent people from suing your. 
But that doesn't stop complaints that this makes Squeak unusable for 
commercial work. I don't agree with that, but you should judge for 
yourself.

> 1) How stable are the two environments?  While I had several
> stability issues with Self at the beginning, they seem to be gone
> now.

I can easily crash Squeak in both Windows and Sparc Solaris. It doesn't 
happen in normal use, and doesn't seem to happen in Linux. The Squeak 
image serving my swiki pages has been running continously since 2000, 
for example.

I didn't understand why one of the goals of the StrongTalk project was 
to create "an industrial strength implementation of the Self 
technology". The Self VM itself has always felt very solid to me and 
looking at StrongTalk I don't see where it improved on that.

It is certainly possible to crash Self, and the Sparc version gives me 
the impression of being slightly more robust than the others. But I 
have done plenty of nasty things to it and had it just keep going.

> 2) How hard is each VM to modify?  Neither seems to have much if
> any comments!  (bad programmers, bad programmers :-)

In theory you get to modify the Squeak VM from within Squeak, while in 
Self you have to mess with C++ and gdb. But often the Squeak 
Interpreter has been broken in the past with several versions of Squeak 
being released before it was fixed. That tells me that in practice a 
different VM development style is being used now.

Depending on what you want to do, Squeak might be simpler to modify. You 
will probably be creating a fork, however, for as I mentioned above it 
is essentially impossible to get your changes into the "official" 
release. See the 3.3 modules effort, Flow, Stable Squeak, "a tale of 
two exception systems" and others for examples.

> 3) The graphics model in Squeak seems to be a reasonable graphics
> model (transforms, etc), but being all in Smalltalk how does it
> perform?

Squeak has 3 graphics models:

 - warp bitblit
 - balloon
 - balloon 3D

All of them are written in Slang (a subset of Smalltalk-80) and were 
translated to C and then to machine language. And at least the last one 
supports hardware acceleration (OpenGL).

On top of that there are several GUIs:

 - MVC
 - Morphic
 - OpenCroquet
 - PenTrails (for Disney PDA, not publicly available)

I think Scratch might have its own GUI, but am not sure.

> 4) What is the relative performance of the two VMs for
> headless programming tasks, and for UI tasks?

UI stuff seems slightly faster in Self on my 277MHz Ultra 5, but on the 
PC or Mac Squeak seems faster.

We would have to run some benchmarks for the headless stuff, but I would 
expect Self to win by a reasonable margin on platforms where it has the 
two compilers (Sparc and Mac).

> I started a company that built one of the first commercial Smalltalk
> applications (still an active product) in 1986, so I know it can be
> done.  The issue today is higher expectations on the part of the
> users, and far faster hardware.  While the hardware should make using
> Smalltalk / Self easier, the graphics requirements seem to do just
> the opposite.  A large Java project I am working on is far slower
> than our Smalltalk app was in 1986 on a Mac II !!!

Running an 8MHz 512KB Mac beside a 1GHz eMac is pretty interesting - the 
latter only seems about twice as fast.

> There apparently is a Java to native code compiler for GCC that
> produces much better performance than the current VMs, has this
> approach been attempted for Self or Smalltalk along the lines of
> Objective-C?  Has anyone tried a Self/Smalltalk to Objective-C
> translator?  Or, are blocks and GC really the performance issues in
> the equation?

A Smalltalk to Objective-C translator did exist a long time ago. I don't 
think translating Java to native code via GCC would be a good idea for 
real applications, though I imagine it would be great for simple 
benchmarks.

-- Jecel