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.