Jecel,
thank you a lot for your historical report. If you will organize your
projects to be open and you will be willing to get some help, I would be
very interested to help with your vision of a system projected in the
future without forgetting the past!

Bye
Enrico
On Feb 22, 2012 8:38 PM, "Jecel Assumpcao Jr." <jecel at merlintec.com> wrote:

> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120223/8cb9d2cd/attachment.htm