[squeak-dev] Re: The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

Igor Stasenko siguctua at gmail.com
Mon Jun 29 23:06:03 UTC 2009

2009/6/30 Göran Krampe <goran at krampe.se>:
> Hi Dan!
> (Watch out - rambling ahead)
> Long time no hear. :)
> Dan Ingalls wrote:
>> Good people -
>> Whatever the impetus, it's good to see this recent spate of
>> self-examination.
> Yep, indeed.
>> When I look back on the early days, we had a cycle where we would use the
>> old system for all it was worth (even with ugly hacks), exploring some
>> current set of initiatives, and *then* we would fall back to clean things up
>> and integrate what we learned in the latest push.
>> Maybe that's what's happening now, but I feel the absence of some of those
>> big challenges that motivate and reward real progress (not to make little of
>> the current efforts).  These could include...
>>    Take advantage of multicore processors and associated
>>    multi-thread OS's in our VM design(s).
> Yeah, I am unsure if Cog has anything in this area. We do have the Hydra
> base, and personally I am quite impressed that Huemul actually has native
> POSIX thread == Process!
> I presume the "perfect" setup is green Processes running on a pool of native
> threads. Thus preserving the "light weight" of Process and still be able to
> utilize cores.
> I also would like to note that while it would be COOL to be able to scale on
> cores - the *reality* is that most apps we write in Squeak that *needs* to
> scale is typically web apps. And you scale web apps horisontally using
> multiple VMs and a load balancer, no big deal.
> So it doesn't really matter how cool it would be - it is not a "killer"
> feature IMHO.
> But the scalability of Erlang would open up new frontiers. :)
>>    Demonstrate real ease of use in tapping that new
>>    dimension of performance.  Linda and E are relevant.
>>    Press at least one good JIT design through to completion
>>    document it, and keep it alive on every platform.
> I presume Cog is our hope? The latest "news" in this area is that Eliot
> mentioned he is looking closer at the JIT in Factor (factorcode.org) and
> even considers porting it! And lots of JIT libs around these days, Nanojit
> in Tracemonkey, libJIT etc etc.
> But one thing is true - performance *kicks ass*. We may go on and on about
> how "unimportant" performance is but darnit, it really is a killer feature
> if we had a REAL fast VM whupping the Pyhon/Rubys. ;)
>>    Make it easy to produce Squeak apps for the iPhone
>>    and similar platforms for which it seems so perfect.
> Mmmm, most such platforms have their "own" UI which you really need to
> adhere to. I think simple interpreters that very easily can play with
> external libs have the upper hand here. Think Python.
>>    Bring Squeak to life in browsers.
>>    OMeta + V8 + Canvas = Squeak everywhere, including
>>    behind firewalls and where installation is prohibited
> Cool yes. Killer feature? Nope, don't think so.
>>    Get serious about security.  Take another look at ESqueak
>>    and figure how to make it just a bit simpler
> Doesn't make me drool. :)
>>    Along the same lines, make it easy for Squeak to rule
>>    the cloud.
> Ah, *that* one is more like it. Not sure HOW, but i do agree that the Cloud
> (in whichever shape or form) is coming.
> One thing I have noted as a consultant is that almost EVERY customer now
> runs virtual hardware. In Sweden almost always VMWare. And this actually
> benefits us - the customer just wants an "appliance". They often don't care
> what it is written in.
> If Squeak could offer something unique in this arena... but I fail to see
> what that could be :)

SqueakNos comes to mind. A modern OS appliance weights hundreds of
megabytes (even gigabytes).
SqueakNos can fit in couple megabytes and handle web/VNC altogether.

>> Each of these has high potential impact, and it would be nice to have made
>> some real progress in one or two areas before doing a major merge or
>> rewrite.  What if you decide to eliminate shared globals; wouldn't this be a
>> great time to include that rewrite?  What if shared variables turn out to be
>> a great way to synchronize multiple threads in the VM;  wouldn't this be a
>> good time to fold that in? Etc.
>> So this may be the time to reorganize everything, but it also looks to me
>> like there is nothing in the way of making some *bold* progress right now,
>> and it's likely that the wider perspective achieved in the process might
>> inform an even better next system.
>> That said, don't forget there are good and committed people on both sides
>> of this discussion, and your first priority should be how to maximize the
>> community.  FWIW I recommend face-to-face discussion. And beer.
> Beer is good. Too bad we are so darn spread out.
>>    - Dan
> regards, Göran

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list