Whither Squeak?

Hi Cees,

As you asked, I'll try to refrain from becoming "opiniative".

I think your diagnostic is great. Incidentally, I said this on the Morphic
list two days ago:

"I'm a bit disappointed that after some initial interest, nobody seems to be
interested in my objectives for Morphic anymore. I want to simplify, clean
and remove stuff. But nobody except for me sent any contribution in that
direction. ... And I see people believing that for Squeak to be 'serious' or
something, we need native widgets or migrate to wxWidgets or such. So
my ideas don't seem popular anymore.

I also believe that we are having serious problems in setting the direction
for Squeak. Even though we all agree we want a small basic image with
optional stuff in SqueakMap, every release gets bigger and bigger. The
community has people with very different interests and it's not easy to
satisfy all of them. And we are failing at setting teams for these different
areas, with the objective of REMOVING their stuff from the basic
distribution, to manage it outside the image. People seem to think that if
something is taken off the image it won't be maintained anymore. I think
this is not true. A package is maintained if and only if some guys with
enough knowledge and interest take care of it, be it in the image or in
SqueakMap."

In my experience in MorphicSplitters and Morphic Stewards teams, it is
entirely possible to remove unwanted stuff, but it is very hard to make
parts unloadable and loadable back easily and cleanly. My Morphic
Splitting efforts are close to a dead end, because of this and lack of time.
The only hope is that each part is handled by people who cares about it,
or simply discarded.

By now, it's obvious. I'm for the "Retry" option:
"- 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)."
But I would be specific on what goes into the image. If something has a
proven team backing it, but it is not truly essential and can be managed
outside the image, then it should not be loaded.
I mean: Traits should go into the image, but not all of the available
browsers,
and perhaps not even SqueakMap support. Better if not even Morphic is
there.

Cheers,
Juan Vuletich
----- Original Message -----
From: "Cees De Groot" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Friday, May 19, 2006 4:43 AM
Subject: 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 :)



--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 5/17/2006

Forget about it, I guess I should understand "Us, board folks..." while
I understood "US board folks..."
Damned email+english is tricky for me

Hilaire

Hilaire Fernandes a écrit :

:)
Smallland
this is true that despite our effort (which bound our hand) people  
preferred
to fork which I can understand. Now this is nice to see that the  
fixes of SqueakLand and SmallLand
have been retroffited into 3.9

> - 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).

:)
exact!

> 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);

Indeed.

> - 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).

I like the idea but with that model so far I would not be able to  
teach or work.

> - 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).

Yes this is true.
May be we could be much more aggressive, there. So far we have been  
quite conservative
I would dream to remove a lot of old code, but was always afraid to  
break too much stuff.

I think that we can play it from both ways at the same time:
        - Continue and really declare 3.9 is the last compatible release and
        start removing large parts, change the method format....

        - at the same time people continue to build Spoon and at one point
        we should be able to meet = using Spoon as the mini-image.

> 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 :)

Now Cees another question is while this is nice to ask the question  
this is
also nice to ask who is doing to do that?

Stef

On 5/19/06, stéphane ducasse <[hidden email]> wrote:
> > - Retry. [...]
>
> I like the idea but with that model so far I would not be able to
> teach or work.
>
Why not?

> I would dream to remove a lot of old code, but was always afraid to
> break too much stuff.
>
That's a valid fourth option, of course.

> this is
> also nice to ask who is doing to do that?
>
It probably depends on the solution chosen. I imagine that the various
solutions will have different supporters. Most important is not who is
doing it, but managing expectations about when results will be
delivered.

About the latter point, by the way, I am very strongly in favor of timeboxing.

Hi,

maintainability of large software collection seems always to be a problem
and a magic bullet is yet to be found. It seems you can either choose
between modularity and effectivity. To illustrate this I want to mention 3
Unix systems I'm using:

Debian testing as a managed monolithic system with strong dependencies,
NetBSD as the same with less strong dependencies and
Mac OSX as an unmanaged modular system (at least partly).

Debian and NetBSD are in my opinion managed monolithic systems because
both have a dependency system and file database. That means you can get
completely rid of previously installed software and it works really fine
until someone breaks the dependency system which happen for me from time
to time on Debian and I can't burn CDs or do other stuff for several days
or weeks just because someone thought the minor version is important.
NetBSD is a bit better because software is build from source and you have
not that often to update a dependency.

Now for the big difference OSX. There is no package system from Apple.
Large chunks of software reside in app bundles and frameworks which is
very modular but on the other hand ineffective. If I want to publish
software based on something not in the base system I put everything I need
in the app bundle. And someone else does the same...

I don't really know what this means in a squeak world but dependency
systems and too finegrained modularity don't seem to work.

Cheers, Torsten

P.S. How would you load the preferred UI System into a MVC and Morphic
free system?

On Fri, 19 May 2006, Juan Vuletich wrote:

> In my experience in MorphicSplitters and Morphic Stewards teams, it is
> entirely possible to remove unwanted stuff, but it is very hard to make
> parts unloadable and loadable back easily and cleanly. My Morphic
> Splitting efforts are close to a dead end, because of this and lack of time.
> The only hope is that each part is handled by people who cares about it,
> or simply discarded.

Although I've never had the time to try it (yet), philosophically, I think Spoon is the way to go.
 
> - 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 best and only way (that I can see) for each Squeaker to have completely their own custom experience, while also, through Naiad or MC, being able to have a *repeatable* experience with other Squeakers (i.e., a "3.8 full" experience, for example).  Its the best of both worlds.  Its the two desired, but divergent, properties that only a machine (the Spoon system) can balance efficiently and effectively.
 
 Once "Squeak" is just this tiny Spoon engine, the Naiad modules become the "content".  Think about how future versions of the now-tiny Squeak-engine will be able to focus much more easily on just the core technical stuff; i.e., a 64-bit Squeak now won't worry so much about about... say, BookMorph compatibility (whatever).  Only the persons who care enough about "BookMorph content" to load it from some master image will be the first to care about that.
 
 The "content" of Squeak will be managed by anyone building Naiad (or MC) modules in Smalltalk.  By having Configurations, content can be shared, or personalized (not shared).  Think about how many "issues" just go away under this model; how many "decisions" and "compromises" and arguments just go away, how many compatibility issues from should be significantly reduced.  It's all up the individual and the Spoon system will keep your image minimized.  Wonderful.
 
 Of course, this all assumes Spoon works as well as I hope it does in my head.
 
 I think a way to get this jumpstarted would be for the standard Squeak download to be an *easy-to-get-started* Spoon system.  A super-tiny image (and necessary VM for each platform) plus the existing [3.8 | 3.9] images as "masters".
 
 I realize this is very bold, but it offers the opportunity to "fail fast" should it fail.  It would probably take a lot longer for the image to start the first time, but maybe that can be mitigated by a) having slightly more than a 2K image to start with or b) explain it in the start-up documentation.
 
 If it actually works, then both worlds can have what they want.  The people who want a small spoon image have it, the people who want content-rich image have it.
 
 Go Spoon!
 

Hi Ralph--

 > ...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 the initial attempts were hampered simply because it's
difficult to remove the very GUIs you're using to do the removal.

        I have successfully removed both Morphic and MVC, as well as all
support for graphics (BitBlt, the Form hierarchy, etc.), and the
compiler, and almost everything else, largely automatically[1, 2]. I did
this by operating on a target memory at a distance, from another memory
where the tools were.

        Of course, the problem of how to delineate and arrange the various
subsystems remains (whether those subsystems are optional or not). While
Spoon offers a way to transfer behavior from one system to another as a
side-effect of merely running it[3], we'll be better off if we create an
intelligible organization. I think an approach that doesn't rely on
source code in files to convey behavior, but instead uses direct
message-based negotiation between running systems, will help a lot. I
think it gives us a much better chance at success than we had before.
You can do a lot of novel sneaky things when you can just inject classes
and methods directly, with live assistance from the target's objects,
rather than having to use the fileysystem and the compiler.

        I'm most of the way through a module system based on direct negotiation
("Naiad", or "Name And Identity Are Distinct")[4].


-C

***

[1] http://netjam.org/spoon
[2]

http://lists.squeakfoundation.org/pipermail/spoon/2006-April/000107.html

[3]

http://lists.squeakfoundation.org/pipermail/spoon/2004-October/000061.html

[4]

http://lists.squeakfoundation.org/pipermail/spoon/2006-April/000108.html

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Hi Ralph--

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

        Yes indeed!

        I'm currently preparing a Spoon snapshot that has every last bit of 3.9
installed back into it (via imprinting), as a proof of concept. Support
for imprinting is available in the most recent Spoon release as part of
a full-featured Morphic-enabled system (albeit a rather old one, of 3.2
vintage, from August 2002). I'm also preparing to make it available
separately as a SqueakMap/MC package, suitable for use in various 3.9
and earlier snapshots. Anyone will be able to move arbitrary behavior
from an old snapshot into a Spoon snapshot.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

I wonder why Pavel don't say he could build a basic console with no MVC and
no Morphic.

I prefer use his old 3.7 kernel and not his new 3.9 , but is my taste.
Others could start from his newer.

Or take Boris procedure for a MVC image if they like MVC.

The hard thing (to me) is how you grow again.

How you go from Spoon (the favorite choice of many) or from Boris MVC or
from Pavel kernel to what we wish ?

How many people realize what current MC1 fails load (in small images what
could understand Monticello and friends) because class initialization is not
fileOut in right order ? (as in Network)

Edgar



       
       
               
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar 

On Fri, 19 May 2006 13:16:35 -0700, Chris Muller <[hidden email]>  
wrote:

> Of course, this all assumes Spoon works as well as I hope it does in my  
> head.

No pressure, Craig! :-)

Hi Torsten--

 > How would you load the preferred UI System into a MVC and Morphic free
 > system?

        The way I've got things now in Spoon, the target object memory starts a
webserver on localhost on startup. By using a local web browser, you can
choose modules to add (and do a few other things, like make snapshots).
You could choose the MVC or Morphic module and load it, ending up with a
running GUI. Modules are provided by other running systems in a
peer-to-peer network.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

Cees De Groot writes:
 > On 5/19/06, st�Aiphane ducasse <[hidden email]> wrote:
 > > I would dream to remove a lot of old code, but was always afraid to
 > > break too much stuff.
 > >
 > That's a valid fourth option, of course.

A fifth option would be to move in smaller steps with a higher quality
level. If all tests were always passing then it would be easier to
assess changes and there would be a greater incentive to write tests.

Having a higher quality bar would make it more difficult to make
large changes like internationalisation and Traits but might free
up some energy to work on the process and the tool support.

My personal suspicion is a few small tool enhancements including
a dependency mechanism for SqueakMap would provide a large benefit.
It's possible that the process tried for 3.9 can be made to work with
some investment in tools. I'm slightly afraid that we'll forever chase
a perfect process and fail to get any process working well.

However, any serious plan for 3.10 or 4.0 whichever one is next would
need a few people to volunteer to lead the effort. As always, it's
those who do the work who get to decide what gets done. Discussion is
valuable but not decisive.

Bryce
P.S. I'm away from the internet for the next week on holiday.

On 5/19/06, Bryce Kampjes <[hidden email]> wrote:
> However, any serious plan for 3.10 or 4.0 whichever one is next would
> need a few people to volunteer to lead the effort. As always, it's
> those who do the work who get to decide what gets done. Discussion is
> valuable but not decisive.
>
I partially agree with that. However, if the community decides on an
option (maybe we could even hold an election if consensus doesn't seem
to be possible), than anyone who would step up would have a clear
mandate. So maybe it is a good idea to define the work beforehand, and
then timebox it, and only then see who wants to pick up the glove.

        Chris writes:

 > Of course, this all assumes Spoon works as well as I hope it does in
 > my head.

        Blake responds:

 > No pressure, Craig! :-)

        Heh... my way of dealing with that is keeping the next couple of fun
things up my sleeve. :)


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

>Hi Ralph--
>
>> ...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 the initial attempts were hampered simply because it's difficult to remove the very GUIs you're using to do the removal.
>
> I have successfully removed both Morphic and MVC, as well as all support for graphics (BitBlt, the Form hierarchy, etc.), and the compiler, and almost everything else, largely automatically[1, 2]. I did this by operating on a target memory at a distance, from another memory where the tools were.

I worked out removal of MVC ages ago.  It left a few pieces of Paragraph as I recall, but it was a push-button operation called discardMVC back in those days.  I see it's still in 3.9, but i wouldn't be surprised if it's not quite "push-button' anymore.

        - Dan

Le Samedi 20 Mai 2006 02:30, Dan Ingalls a écrit :
> I worked out removal of MVC ages ago.  It left a few pieces of Paragraph as
> I recall, but it was a push-button operation called discardMVC back in
> those days.  I see it's still in 3.9, but i wouldn't be surprised if it's
> not quite "push-button' anymore.
>
>         - Dan

Sounds like bootstrapping... Nobody surprised that we have to bootStrap when
constructing, why the same would not apply when deconstructing ?

Nicolas

On Fri, May 19, 2006 at 05:30:41PM -0700, Dan Ingalls wrote:
>
> I worked out removal of MVC ages ago.  It left a few pieces of Paragraph as I recall, but it was a push-button operation called discardMVC back in those days.  I see it's still in 3.9, but i wouldn't be surprised if it's not quite "push-button' anymore.
>
> - Dan

I don't want to complain about something when I don't have a constructive
solution to offer, but I can't help mentioning something here. There
is a great deal to be learned from the Squeak image, including concepts
and implementations that have survived *in the image* for decades. But
various well-intentioned efforts to improve, update, clean, enhance,
and modularize Squeak (call it what you will) are having the unintended
consequence of damaging its historical context.

Case in point: SystemDictionary>>discardMVC was stamped by 'di' as of
April 1999.  But in any recent image, I would be led to think that this
method was attibutable to 'sd' and that it was originally written in
September 2004. There is absolutely no way for someone to look at a
current Squeak image and figure out that Dan ever had anything to do
with it. And if I had not seen this email, I would not have thought to
dig out an old image and see if it would still run long enough to find
out who really wrote the method.

Similarly, the well-intentioned modularization of the system would lead
a newcomer to conclude that the entire object memory, virtual machine,
and interpreter were recently created by someone with the initials 'tpr'.
Worthy initials indeed, but rather misleading when the version histories
show no prior authors.

This is not just a matter of authorship. If I were to try using the
#discardMVC method, it probably would not work. Looking at the method
history, there would be nothing to clue me in as to when it last did
work, or even whether I might reasonably expect it to have worked at
any time in the past. But if I knew that the 'di' stamp was in effect
as of about 1999, I would know that it did in fact work at some time
in the past. I would know that if I were to pull out an old image of
that general vintage, I would have a resonable chance of seeing it work,
and some way to figure out how to update it for a current Squeak image.

I do not in any way mean to diminish the contribution of folks whose
initials do not happen to be 'di', but for me it really takes a lot of
value (and enjoyment) out of the image when I can no longer look at the
version history of methods and classes and get a sense of where they
come from, who created them, and when they were done.

I'm sorry that I don't have a constructive suggestion to offer, but I
think it would be really nice if we could come up with a way to preserve
this kind of contextual information as we evolve and improve the image.

Dave

On 19-May-06, at 8:54 PM, David T. Lewis wrote:


>
> Similarly, the well-intentioned modularization of the system would  
> lead
> a newcomer to conclude that the entire object memory, virtual machine,
> and interpreter were recently created by someone with the initials  
> 'tpr'.
> Worthy initials indeed, but rather misleading when the version  
> histories
> show no prior authors.
Well, much as I like credit for what I do, losing the version history  
is a real bummer. I like to know who to blame for each previous  
change. One of the few things I dislike about MC is the lack of  
version history included in the package info.

How did we lose the info? It doesn't seem to be the basic mechanism  
at fault because I see versions of stuff I've been working on today,  
for example. Hmm, that's a 3.8 based image so clearly it is not a  
completely recent thing.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Sona si Latine loqueris = Honk if you speak  
Latin.

> From: Torsten Sadowski
[...]
> There is no package system from Apple.
> Large chunks of software reside in app bundles and frameworks which is
> very modular but on the other hand ineffective. If I want to publish
> software based on something not in the base system I put
> everything I need
> in the app bundle. And someone else does the same...

Yes.  Microsoft have gone down the same route with .Net (and, in fact,
with their application recommendations since the betas of Windows 2000 -
about 8 years now).  It's the only way they've found to prevent the "DLL
Hell", or more generally dependency hell, that plagues modular systems.
It also means that an app bundle is standalone, requiring nothing more
than a base system and certainly not requiring access to a package
repository.  I don't know about you, but the incidence of applications
that won't run because of incompatibilities has fallen markedly on the
systems I manage since that time.

I'm interested.  Why is this 'ineffective'?

                - Peter

>
>> this is
>> also nice to ask who is doing to do that?
>>
> It probably depends on the solution chosen. I imagine that the various
> solutions will have different supporters. Most important is not who is
> doing it, but managing expectations about when results will be
> delivered.

I thought that naively who is doing it is the most crucial part (if  
someone does it)

> About the latter point, by the way, I am very strongly in favor of  
> timeboxing.
What does it mean?

Stef