Squeak Oversight Board minutes – 02/21/12

Chris Cunnington wrote on Wed, 22 Feb 2012 10:16:41 -0500
> - Jecel will not be running for the SOB again to concentrate on his Smalltalk fork
> called (provisionally) NeoSmalltalk. It allows several images to run on a single vm
> and work in concert

Below is a *very* long version of this, but you don't have to read it
because the short version is: my plan is to work on getting Squeak 4.3
to run on the SiliconSqueak processor during the first half of this year
and then work on a very simple Smalltalk to run side by side with Squeak
in the second half of 2012. This might cause some conflict of interest,
so I think it would be a bad idea for me to be on the board. Being part
of the board for the past three years has been a very positive
experience and if it turns out (as is likely) that there are no
conflicts of interest then I would be happy to run again in 2013.

Anyone curious about this project might find this presentation from a
year ago interesting (though the simple drawings don't make much sense
without the narration):

http://www.merlintec.com/download/jecel1cwlcr.pdf (1MB)

Now for the very long version:

John Maloney invited me to the Squeak community a little before it
became public. I had previously been a part of the Smalltalk and Self
communities having started building Smalltalk hardware in 1984. Though
my contributions to Squeak have been very small, I feel my participation
has often helped bring a historical perspective to the discussions (this
was particularly useful during the relicencing effort).

Part of the community wanted to use Squeak as just a starting point for
something that might turn out very different. Alan Kay said so in his
1997 OOPSLA keynote talk. And certainly if you look at what is going on
at VPRI or what Dan Ingalls has done in the Lively Kernel you can get a
good feel for what they were talking about. But there was a large part
of the community that just wanted Squeak to be a free alternative to
VisualWorks.

Around 1994 I had dropped the hardware side of my project since PCs were
advancing so quickly (the Be and NeXT people felt the same, among many
others at the time). But by 1998 I felt I could have a much better
performance/cost ratio with a design optimized for Smalltalk. FPGAs had
advanced enough that you could fit a whole processor inside them and
they had become cheap enough so you could use them in an actual product
rather than just the prototype.

Sun had killed off the Self community by shutting down the servers used
for downloading the software and papers as well as for the mailing
lists. So I proposed to the Squeak community a roadmap to add all the
neat technology I had been working on in Self to Squeak:

- a new event system to make Squeak into a nice and secure OS
- a modular alternative to images
- a simpler base model with a compatibility layer for running all the
old stuff

The reaction was roughly "if I wanted to program in Self then I would
use Self. I want Squeak to be Smalltalk-80". I had been using my
university's computers to run Self up to that point and didn't have a PC
fast enough to make Squeak practical. So my choice was to either buy the
fastest PC available for Squeak or a Sun Ultra 5 for Self, and I did the
latter. I also created a new "self-interest" mailing list on eGroups
(now YahooGroups) and was able to ressurect the Self community
(currently being lead by Russell Allen). I continued to participate in
the Squeak community, but my project was not related to it.

A lot of people complain about how many years I have been working on my
designs with no concrete results. They are partly right to do so, but
when you compare to one a single person with practically no financing
has done with what, for example Transmeta took five years to do with a
large and well financed team I don't think it is as bad as it initially
seems.

The main Smalltalk processor was:
- Tachyon (1998-2001): four slot MOVE architecture with large external
cache
- Plurion (2001-2003): multiple stack machines with three level stacks
- Neo32 (2003-2006): multiple stack machines with dual stacks
- RISC42 (2006-2008): 32 bit RISC with 16 bit instructions optimized for
adaptive compilation
- SiliconSqueak (2008-2010): bytecode machine with 32 bit microcode
- SiliconSqueak (2010-now): bytecode machine with 16 bit microcode and
ALU Matrix

In parallel with this, I had been working on a much smaller processor
(an alternative to the Atmel ATMega used in the popular Arduino boards,
for example) for a terminal for truck drivers that a client wanted to
sell:

- Oliver (2001-2003): patched MISC Forth processor for object
orientation
- dietST (2003): very reduced Smalltalk processor to fit in smallest
FPGA
- Neo16(2003-2006): simple stack machine with dual stacks

In 2007 I started a master's project at the local university and the
pace of the project became even slower. In 2008 Merik Voswinkel was
proposing the "SqueakPhone" as an alternative to Apple's closed iPhone
and we decided to join forces. Some of the people already working with
him had already invested a lot in Squeak and asked me if my hardware
couldn't be modified to run that instead of my own Neo Smalltalk
(previously Self/R and Merlin OS before that). I had already
investigated the idea of a Squeak processor back in 2004 and decided
that the result would be good enough. We could probably make some
interesting products with Squeak as it is plus Etoys or Scratch and then
we could move on to more advanced stuff. While the SqueakVM is large and
awkward compared to some others I had worked on (Neo32 is a good
example), this really doesn't make any difference to the end user. We
could run Squeak on the Strongtalk or Self VMs or run Self on top of the
Squeak VM and the language level would be the only one to make an
impression.

As part of the Squeak community, I had watched Ian Piumarta fail twice
to get the community to adopt his JITs. Henrik Gedenryd failed to get
modules adopted and Anthony Hannan didn't get any takers for this
closures nor his new bytecodes. And I had failed in 2005 to get the
community to participate in the new OLPC project. But in 2008 I saw the
community welcome Eliot Miranda's new Cog effort and the board's
discussion to base Squeak 4 on Spoon (changed to Squeak 5 as Squeak 4
was redefined to be a license change instead of a technical one) and
thought that perhaps the time had come to move Squeak forward.

Now don't get me wrong - I am against moving forward by breaking a lot
of stuff. And I think we have made a commitment to the Etoys users and
can't simply decide to stop supporting their needs. It only seems you
can't have it both ways when you are focused on the details of day to
day development. If you step back and look at the big picture then you
might find a solution.

Let me give you an example: though I was really excited when the Mac
came out and still love it, knowing everything I know today I feel it
was a huge mistake that nearly killed the company. If they had instead
created an Apple IV with roughly the same features but capable of
running the old stuff inside of virtual Apple IIs, each in its own
window, then they would have been far more successful.

Just wanting to have both progress and access to the old stuff is not
enough. Having watched a few talks about the future of Pharo, it seems
that they want this (both a really stable free alternative to
VisualWorks for serious business applications and a research platform
for their students) but I have not yet seen a plan to achieve this.

My own solution is to run different systems on the same platform (the
Squeak VM) and have a standard inter image communication system so an
application can use Squeak, Pharo, Cuis, Spoon, OpenQwaq, OpenCobalt,
Scratch, Etoys, Newspeak and others at the same time. That would allow
us to change one as radically as we want while not breaking anything
since all the old stuff would continue to be available.

Most, if not all, of the work needed for this already exists in
scattered pieces. For example: we would need to be able to show objects
that live in different images on the same screen. Like in Nebraska and
several odd projects from Japan that I can't remember the name of right
now.

Anyway, in such an environment it would be possible to keep all the
current stuff running and have Squeak change as little as people want. I
can keep using Celeste to read and write my emails, for example. At the
same time I will be free to throw out classes, globals and textual
syntax, replace the image with modules and do anything I feel is
important without upsettting anyone. The previous idea of slow and
steady changes to Squeak had the problem that, as I always like to say,
you can't add simplicity, only complexity.

-- Jecel