[squeak-dev] Jecel is not running this year (was: Squeak Oversight Board minutes - 02/21/12)

Casey Ransberger casey.obrien.r at gmail.com
Thu Feb 23 23:20:56 UTC 2012


Top-post:

Bummer! I'm excited about your hardware work, silicon isn't something
that's fast and easy, so I've been fine with waiting. I've learned just
enough about this stuff to realize how enormous what you're doing really
is, and I commend you for seeing the work through.

FWIW, I don't buy your conflict of interest argument though;) and I think
you should run again anyway.

Thanks for serving on the board, especially with regard to your work in the
relicensing effort, and for all of your thoughtful comments both on the
list and elsewhere. You bring an ocean of perspective to this community.

Remind me to bother you again about making an Apple IIgs from scratch:)

Don't leave town!

On Wed, Feb 22, 2012 at 12:35 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
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120223/d6b95f39/attachment.htm


More information about the Squeak-dev mailing list