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 :)

> 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