2009/6/30 Göran Krampe goran@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