Göran Krampe wrote:
> Gotta chime in somewhere here and since Jecel mentioned DS... :)

It wouldn't make sense to make plans for the future while ignoring stuff
that is being developed.

> Jecel Assumpcao Jr wrote:
> > I want it to be easy and elegant to create and share persistent objects
> > using Squeak.
> > 
> > Solutions like Monticello+package universes/squeakmap are a bit too
> > complicated for me and yet don't do some things that I want.
> 
> I don't associate those tools much with "persistent objects", mostly 
> (well, SM can do Projects so sure...) with source code.

True, as the other thread about SAR vs MC shows. Some people would love
a source-only Squeak but that is not the direction I want to go - I
don't want to have to write some method to get something like the old
"Play with me" windows, for example.

> > Deltastreams would improve that somewhat.
> 
> Eventually and hopefully. Since Brest I haven't had any time at all to 
> put on "private Squeaking" though. But it is still there on the back 
> burner. :)

In this discussion we haven't specified dates, so I imagined a roadmap
of at least a few years.
 
> Otherwise I:
> 
> - Really like what Andreas wrote. :)
> - Will hopefully work on web stuff using Seaside in near future "for pay".
> - Continue working on Gjallar and DeltaStreams.
> - Will work on improving the CouchDB client code.
> - Am highly interested in getting Squeak running on Android, in whatever 
> fashion. I am trying but its... hard to merge build systems etc.
> - Really want Squeak to "move on".

Great plans!

> We shouldn't be too afraid of changing and fixing stuff! I really like 
> the latest Set/Dictionary improvements - for the simple fact that 
> somebody actually DARES to touch that stuff again. More, more!

It is also interesting to have discussions around the changes. You will
never make everybody happy, but it is good to listen to what they have
to say. In the end, though, I always like to point out that older
Squeaks will always be there and are a valid option for those who can't
deal with the current changes.

> If we could also get say... some really slick concurrency mechanisms 
> (Promises? Asynch messages?) either into a really good library and/or 
> into the language - I really think we should stop being so afraid of 
> modifying the language and its core. That is my incoherent point really.

As I implied in my previous email, I am embedding remote message passing
into the send bytecode itself. I know many people hate that and will
quote famous papers showing how stupid it is to treat local and remote
messages the same. But I don't agree - to me what is stupid is to think
that local messages won't fail (why have an exceptions framework,
then?), won't timeout (how about an infinite loop in #drawOn:?) and so
on.

> Regarding Pharo etc, IMHO it's "just a fork". And forks are good. 
> Really. :) As long as we don't build fences between them (mentally or 
> technically).

Unfortunately it is a bit harder to exchange code between Squeak, Etoys,
Pharo and Cobalt using Monticello instead of changesets. Geeting stuff
from Cuis into the trunk seemed to happen easily enough, though since I
wasn't the one who did the work I can't be is this impression is
correct.

> PS. I really love all the exciting stuff on vm-dev (threaded VM, Cog, 
> event based VM etc).

Yeah, it isn't easy to keep up.

-- Jecel