>
> Because the way of Smalltalk is a image in chicken and egg cycle and any
> image comes from previous one, mutating in the process.
>
>   
Dear Edgar,

That is precisely the problem.

How many chickens lay their eggs while crossing the road. Chickens
normally sit down to lay their eggs.

How many eggs hatch while rolling down the hill? Normally they are
stationary, if not the new chick is going to get dizzy with confusion.
> And Smalltalk is about objects and not about scripting.
>
>   
One person (a bottleneck) incrementally adding things to an image is
easy, and inevitably the image grows.

Modularizing and refactoring an image made up of interdependent parts is
harder it takes foresight and planning.

We want to empower everyone to contribute to parts of the core image in
parallel. When I work on a task (like refactoring SourceFiles for
example) I don't know how long it is going to take. What are the chances
of my efforts being ready at precisely the time that the release team is
ready to use my effort? Basically virtually zero.

So... if I can continuously integrate my work into a public (or private
to me) "unstable" release, I get to receive potential feedback as early
as possible ("fail fast = learn fast").

One other thing, when one person is incrementally tweaking the image
that everyone is relying upon there is a lot of pressure to be perfect.
This is really "not fun", it is usually quite painful (don't you know
that feeling?) This alone is perhaps responsible for the painfully slow
release cycle that squeak has had over the past  few years.

In the past a new module like Rio would have to be perfect before
getting into an image, and even then it might take 2 or more years to
gain acceptance. Dare I mention Namespaces?

With this scripting approach we have a platform in which non perfect
contributions can be included in the unstable releases. You dont have to
wait for the release team to buy into your idea, you can throw it into
the unstable release, and get it seen. Then when the release team
decides not to include it you can still load your "task" if you want to,
and make it available to others. The basic release can be shipped
including "the unstable tasks" that you can apply if you want to. This
releases unstable tasks are the next releases potential stable ones.

We then have scope for planning the movement of unstable contributions
to stable ones. For some of us, we really produce our best work when we
are working in a team. But for most of us we are coding in squeak on our
own. The tools can facilitate the not yet perfect packages reaching
others who might form a team effort to knock them into shape.  Matthew
and I have been doing this with Monticello15 for the past year, and it
works really well, with a well defined module. This can be extended to
the core with help from scripting and tools.

If we improve the tools with atomic loading where things can be loaded
and unloaded (more) easily we can tackle the core image where it was
harder to do before and free everyone from the tyrany of perfectionism.

Did your hero Pavel not achieve the kernel image through Scripting? I
think so!

regards

Keith