Whither Squeak?

Us board folks have been discussing where to go from here and I
personally would like to see a lot of discussion on this on
squeak-dev, so I am going to completely unofficially kick off this
discussion :-).

I'll present this as a set of bullets, I think it would be nice if we
could have a round of brainstorming first to complete these lists
before becoming opiniative.

Pressures:
- Squeak 3.x is so far quite succesful in resisting us applying
software engineering efforts to it. The reasons are manifold, but two
major reasons are manpower and available tools, neither is going to
change any time soon;
- It looks like squeak-dev is on its own, with the two main projects
that are using it (SqueakLand and Croquet, of course) effectively
having forked. There always has been a perceived need to be stable to
support these projects, but in howfar that is necessary at present is
open for debate;
- There is an awful amount of ideas, and an awful amount of talk about
what hasn't been done to Smalltalk since Smalltalk-80. Some of these
ideas were bad, a lot were good but haven't been implemented, and some
have been implemented. I think the number one reason for not
implementing good ideas is inertia due to having to support a large
codebase (see the point about SqueakLand and Croquet).

Possible solutions (given in "who is General Failure and what is he
doing on my drive?" style):
- Abort. Go back to the SqC model and live with a monolithic image (do
not scale);
- Retry. Declare Spoon to be Squeak 4.0, declare that that is all that
is going to be "officially" supported for the time being, and refuse
to support anything additional that doesn't have a proven team backing
it (scale up).
- Ignore. Keep on following the (distributed) software engineering
trail, but realize that it may take 5 years before we have a
modularized, manageable Squeak (scale down).

I have a clear preference, but I am not giving it until after a bit of
brainstorming here on the list. I hope that the rest of you will be
able to show the same restraint :)

Hi Cees,

on Fri, 19 May 2006 09:43:55 +0200, you <[hidden email]> wrote:
...
> Possible solutions (given in "who is General Failure and what is he
> doing on my drive?" style):
> - Abort. Go back to the SqC model and live with a monolithic image (do
> not scale);

No problem, after doing the next step (explained below).

> - Retry. Declare Spoon to be Squeak 4.0, declare that that is all that
> is going to be "officially" supported for the time being, and refuse
> to support anything additional that doesn't have a proven team backing
> it (scale up).

This is the next step, IMO. Spoon allows to create as many monolithic  
images as are needed and the production process is redoable.

> - Ignore. Keep on following the (distributed) software engineering
> trail, but realize that it may take 5 years before we have a
> modularized, manageable Squeak (scale down).

With (nontrivial) software development it is the same as with hardware  
engineering: if it is never tried out, one can never find out.

It is perhaps desirable to first create a roadmap (with milestones) in  
order to always be able to check with the community whether the next  
action should be abort, retry or ignore. Having such a plan would give the  
community something which often looks as if it where absent: confidence.

/Klaus

and therefore can't log in to my account "ts".


Is there anything that can be done about it?

Cheers, Torsten

Cees De Groot a écrit :
> Us board folks have been discussing where to go from here and I
> personally would like to see a lot of discussion on this on

Can you define "Us board"? I know about something called the squeak
foundation board, but I don't know what is "Us board"

Hilaire

On 5/19/06, Cees De Groot <[hidden email]> wrote:
> - Squeak 3.x is so far quite succesful in resisting us applying
> software engineering efforts to it. The reasons are manifold, but two
> major reasons are manpower and available tools, neither is going to
> change any time soon;

What does this mean?  Is this another way of saying "A lot of people
have been trying to modularize Squeak and we haven't gotten very far."

I'd like to see some of the concrete problems that rose during
attempts at modularization.  Why is it so hard?  For example, I have
heard that people have tried to strip Morphic out of the image, and
they have tried to strip MVC out of the image, and both have failed.
Why did it fail?

I think this is a very interesting question, and understanding why it
failed will teach us a lot about software in general.  If it is hard
to modularize code in Smalltalk, which is one of the most flexible and
visible languages in the world, imagine the problem modularizing the
Linix kernel!

Is this what you mean?

-Ralph Johnson

On 5/19/06, Cees De Groot <[hidden email]> wrote:
>
> - Retry. Declare Spoon to be Squeak 4.0,

Is it possible to start with Spoon and then load in the rest of the
Squeak codebase?

If so, we should make Spoon be "Squeak light" and the rest "Squeak
overwight" and keep modularizing it.

-Ralph

Ralph Johnson puso en su mail :

> Is it possible to start with Spoon and then load in the rest of the
> Squeak codebase?
>
> If so, we should make Spoon be "Squeak light" and the rest "Squeak
> overwight" and keep modularizing it.
>
> -Ralph
I know I'm a beginner and what Craig work is amazing.
But SqueakLight is my child, born as 3.7 hand cut image to 3.6 minimal
following Pavel and others (mine too) cutting tricks.
Currently I have several experimental images for learn the dependency
business the hard way.
And some how to grow to say have mp3 again or have gif/png/jpg reading write
again, loading MorphicWrappers, loading MC1 (and 2) , improving
compatibility to point of could read any originated in 3.8 or 3.9 (and
Morphs created in 3.8 or 3.9) , etc
I have this pieces to minimal what could load and call "emporwements" and
follow .sqz compression and logic for loading.
And have a repository of normal classes in .st and .sqz formats and
something for "learn" from this repository if something was ripped by
cutting and is needed.
My baby could do any what 3.9b could do (no Traits, no Etoys) in sizes what
vary from "below 4 Mb" to 7 Mb depending of what you wish.

I wish say very thanks for all you did for Smalltalk as I follow all courses
and material what I can find and download for learn from you.

Edgar



               
_________________________________________________________
Horóscopos, Salud y belleza, Chistes, Consejos de amor:
el contenido más divertido para tu celular está en Yahoo! Móvil.
Obtenelo en http://movil.yahoo.com.ar

Torsten Sadowski <[hidden email]> wrote:
> and therefore can't log in to my account "ts".
>
> Is there anything that can be done about it?
>
> Cheers, Torsten

Yes. :) (check your inbox)

regards, Göran

I had the same problem,
i contacted squeak.org but i had no response... my nickname is let.

Thanks.

On 5/19/06, [hidden email] <[hidden email]> wrote:

--
www.italianpug.org - Italian Python User Group Founder
www.lethalman.net - Thoughts about computer technologies

On 5/19/06, Ralph Johnson <[hidden email]> wrote:
> What does this mean?  Is this another way of saying "A lot of people
> have been trying to modularize Squeak and we haven't gotten very far."
>
Yup. Good summary :-).

As to the why: certainly not a lack of brainpower. Squeak ports some
of the brightest minds in the industry. Manpower is probably reason
number one, coordination is tricky as well, and the tools have
performance problems when trying to manage the whole image.

On a more philosophical stance, Squeak has grown organically. And
anything organic tends to get fuzzy, maybe even almost fractal,
borders between the various parts. Try separating a leaf from its
stem, on the cell level, for starters...

You can also check your inbox. :)

And to all other newcomers - I am the SqueakMap maintainer etc so just
email me about problems. Or at least put my private email on the CC-list
so that I don't miss it.

regards, Göran

Lethalman <[hidden email]> wrote:

As usual, thanks :)

On 5/19/06, [hidden email] <[hidden email]> wrote:

--
www.italianpug.org - Italian Python User Group Founder
www.lethalman.net - Thoughts about computer technologies

> > What does this mean?  Is this another way of saying "A lot of people
> > have been trying to modularize Squeak and we haven't gotten very far."
> >

> Yup. Good summary :-).

> As to the why: certainly not a lack of brainpower. Squeak ports some
> of the brightest minds in the industry. Manpower is probably reason
> number one, coordination is tricky as well, and the tools have
> performance problems when trying to manage the whole image.

> On a more philosophical stance, Squeak has grown organically. And
> anything organic tends to get fuzzy, maybe even almost fractal,
> borders between the various parts. Try separating a leaf from its
> stem, on the cell level, for starters...


        http://www.kitchenculturekit.com/index.htm


    Hope this help ;-)

    Cheers,

    SmallSqueak

>
> If so, we should make Spoon be "Squeak light"
> and the rest "Squeak overwight" and keep modularizing it.
>

    I think there is a typo here, should it be :

        "Squeak overnight" and keep modularizing it.

    I can easily picture people Squeaking over night
    to keep modularizing it.

    I am so excited.

    Cheers,

    SmallSqueak

----- Original Message -----
From: "Ralph Johnson" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, May 19, 2006 8:25 AM
Subject: Re: Whither Squeak?

On 5/19/06, Cees De Groot <[hidden email]> wrote:
>  the tools have
> performance problems when trying to manage the whole image.

Can you be specific?  What tools?  Can you give stories of how tools failed you?

> On a more philosophical stance, Squeak has grown organically. And
> anything organic tends to get fuzzy, maybe even almost fractal,
> borders between the various parts. Try separating a leaf from its
> stem, on the cell level, for starters...

Squeak is a bit more extreme than others, but not a lot.  As Fred
Brooks said, all successful large systems started as successful small
systems.  Organic growth is typical, not atypical.  Refactoring is a
lot of hard work and Squeak doesn't have people being paid to do this
kind of work.  But I find it hard to believe that Squeak is worse than
Word, or Gnu EMACS, or any other large system that has been around for
a long time.  The difference is that Microsoft pays people a lot of
money to modularize Word.  It goes though periods of organic growth,
and then periods of modularization as they try to reuse code across
projects or within Word.  Most software does this.

This is why I think modularizing Squeak is an interesting project,
because we can learn lessons from it that will apply to all software.
So, we need to write about what we are doing, the problems we
discover, and the lessons we learn.

Squeak hasn't needed to be modular enough for people to do the work to
make it so.  Now it does.  (Well, it probably has for several years,
so "now" means "the last few years".)

-Ralph Johnson

On 5/19/06, Ralph Johnson <[hidden email]> wrote:
> Can you be specific?  What tools?  Can you give stories of how tools failed you?
>
I think Stephane and Marcus, the Brave Two Men who did all the hard
work on 3.9, have some stories to share. Monticello was one of the
tools that showed scaling problems when trying to apply it to the
whole image, and the second big issue, which is a bit unique to
Squeak, I think, is that we're trying to deconstruct a living thing:
we still need to find a way to manage live objects outside the
image...

> The difference is that Microsoft pays people a lot of
> money to modularize Word.
>
Yup. That's the issue here - a lot of money...

On 19 mai 06, at 16:51, Cees De Groot wrote:

> On 5/19/06, Ralph Johnson <[hidden email]> wrote:
>> Can you be specific?  What tools?  Can you give stories of how  
>> tools failed you?
>>
> I think Stephane and Marcus, the Brave Two Men who did all the hard
> work on 3.9, have some stories to share. Monticello was one of the
> tools that showed scaling problems when trying to apply it to the
> whole image,

Basically atomic loading and the load time was a problem.
I hope that MC2 will solve that.

Besides that I think that we could cut it and make more modular but  
it requires
time/energy/money :)

> and the second big issue, which is a bit unique to
> Squeak, I think, is that we're trying to deconstruct a living thing:
> we still need to find a way to manage live objects outside the
> image...
>
>> The difference is that Microsoft pays people a lot of
>> money to modularize Word.
>>
> Yup. That's the issue here - a lot of money...

I have managed to strip MVC from an image, save some basic text editor
stuff. It is possible.
Part of work on creating a basic deployment image.
It was pretty hairy though!

Would be nice if MVC (Morphic would be much harder) could be optional.

As for compatibility, most people work with what they are given and utilise
it, leading to
complex dependencies. Perhaps an automated packaging system based on MC2
where tracking of what you
use creates explicit dependencies (implicitly) while you work would be
useful.

Hi Göran,

I also tried to register (Janko Mivsek, jm as initials,
[hidden email]) and first it said that something was wrong ....
When I repeated with different initials, it complained about e-mail
address already taken, when changed initials back, it complained about
initials already taken ...

Can you help me too?

Thanks and best regards
Janko

[hidden email] wrote:

Il giorno ven, 19/05/2006 alle 09.43 +0200, Cees De Groot ha scritto:
I propose another course of action:

- Steer. Let's take another SW engineering trail which, albeit with some
tradeoffs, will bring us  to a modularized, manageable Squeak in less
than 5 years. Let's try to have a time-boxed schedule: it has done
wonders for other Open Source projects such as Gnome or Ubuntu. Let's
burn the diskpacks: let's drop MVC, move to Flow for network and files,
move to OmniBrowser and have an interface for Extract Method
refactorings which even I can understand (now, these are just examples
of things we could possibly do, not real proposals - not yet anyway).

        Giovanni

PS. Given my track record as a Squeak coder (4 lines submitted), please
excuse my blatant abuse of "let's"es and "we"s ;)