Whither Squeak?

> Hi Daniel, Ralph,
>
> I think Daniel is absolutely right in his focus on cyclic  
> dependencies. The difficulty in decomposing Squeak is because of  
> the interaction of three factors, IMO:
>
> 1) It's awfully difficult to collaborate, especially in ad-hoc,  
> distributed communities, without good version control
>
> 2) Monticello doesn't deal well at all with large, monolithic  
> bodies of code or cyclic dependencies
>
> 3) Squeak is large, monolithic body of code rife with ill-defined  
> and often cyclic dependencies
>
> As a point of comparison, look at the Seaside sub-community.  
> Seaside2 has been under version control for its entire life, and  
> the Seaside community has generally adopted Monticello for their  
> Seaside projects. The issues we've struggled with and repeatedly  
> debated in Squeak have been resolved without much discussion or  
> effort in Seaside. The code base is modular and generally-well  
> factored. Most packages are reasonably well maintained, but even  
> packages with absentee maintainers tend to get fixes and "hacked"  
> versions are available in one place or another. This works because  
> the Seaside community just treats the underlying platform as a  
> mostly opaque substrate and builds everything on top of it.
>
> More comments inline:
>
> On May 20, 2006, at 6:42 AM, Daniel Vainsencher wrote:
>
>> Package system:
>> --------------------------
>> I believe that the management of the code of Squeak in tool  
>> supported packages is a critical component of any solution - this  
>> is the only way to keep the boundaries up to date. So the  
>> existance of MC exists makes this task somewhat feasible, but  
>> there have been various problems with its use to manage the whole  
>> image.
>>
>> - Performance (loading updates to the image using MC is much  
>> slower than loading changesets).
>
> There are several aspects to this, but the primary one is that MC  
> doesn't version code so much as packages. Because of the dependency  
> issues in Squeak, packages are either really big, or a "small"  
> change touches a lot of them. Either way, it means moving a lot  
> more data and doing more work to update image than what is required  
> for a change set. In practice, that makes it too slow everyday  
> workflow.
>
> MC2 actually versions code, so it has a lot more flexibility. It  
> would be possible, for example, to create an update stream of  
> "versioned changesets" that wouldn't carry too much overhead  
> compared to the classical update stream.
>
>> - System changes (like introducing Traits) require going through  
>> various intermediate stages, but MC itself only model merging the  
>> code in order to reach the final stage to be loaded.
>
> Yes. It's surprising how little this has affected at the higher  
> levels of the system. (For example, MC can usually update itself  
> without problems.) To manage all of Squeak, though, I don't think  
> we'll be able to escape having some kind of update stream based on  
> filing in arbitrary code.
>
> MC2 can help with this part as well. It can do atomic updates to  
> the image, so the cases that require carefully orchestrated  
> migrations should be very rare. I'm imagining only issuing updates  
> every year or two, and having stuff stay pretty compatible in  
> between updates.
>
>> - Workflow:
>> -- Support for cherry picking is very basic in current MC (which  
>> MC2 should improve).
>
> Yes. Cherry picking is surprisingly important, and MC2 should do  
> merges in general better than MC1 does.
>
>> -- MC is quite workflow agnostic, but maintaining Squeak does  
>> require some workflow (people write fixes, other people merge  
>> them), and maintaining it as a set of packages requires even more  
>> of it (coordination of entry of package changes into the official  
>> release). Right now we use a combination of SqueakSource, Mantis,  
>> and email, glued together by (what seems to me like) lots of  
>> overhead.
>
> Breaking the dependencies is hard work. Monticello is making it  
> even harder, because it's really meant to work on systems that are  
> already decomposed. It expects to work on packages with stable  
> boundaries and acyclical dependencies, and ties versioning very  
> tightly to that model. It's too early to say yet, but since MC2  
> does versioning without requiring packages, I'm hopeful that it can  
> help with the modularization workflow more effectively than MC1.
>
> Colin
>

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of stéphane ducasse
> Sent: Saturday, May 20, 2006 2:32 AM
> To: The general-purpose Squeak developers list
> Subject: Re: Whither Squeak?
>
> >
> > 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 think that we can talk and create teams and ...
> at the end of the day if people do something it happens (see MC1,
> MC2, OB, harvesting).
>
> So I would love to see a spoon-based system (= for my mini image +
> loadable modules)
> but I tend to stay away from the team kind of calls where the team
> work one week and
> fall apart. (of course this is not the case of Craig) but what we are
> facing now is that
> really few people proposed to help for 3.9 harvesting. So each time,
> we have big discussions
> about big great plans and people oppose small steps and large ones.
> I would say: give me 4 cool developers for 2 years and I will jump in
> big cool plans, now
> if you have 2 guys working the night....I let you conclude.
>
> > Bryce
> > P.S. I'm away from the internet for the next week on holiday.
> Good!

>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

> Classes are not modules.  A module will include methods added to other
> classes.  So, it is possible for class A to refer to B and class B to
> refer to A, but A and B are in different modules with no cycles.
> Suppose class A is in module X, and it depends on module Y, which
> contains class B.  Then the method in B that refers to A is actually
> part of module X, even though most of B is in Y.
>
> I don't know the example you are talking about, and it might very well
> be an example of something that needs to be fixed.  But the fact that
> Object has an "inspect" method doesn't mean that the entire GUI is in
> the same module as Object.
>
> This *does* make a system difficult to decompose because you can't
> assume that you can just assign classes to modules and be done.

>> I believe that the management of the code of Squeak in tool  
>> supported packages is a critical component of any solution - this  
>> is the only way to keep the boundaries up to date. So the  
>> existance of MC exists makes this task somewhat feasible, but  
>> there have been various problems with its use to manage the whole  
>> image.
>>
>> - Performance (loading updates to the image using MC is much  
>> slower than loading changesets).
>
> There are several aspects to this, but the primary one is that MC  
> doesn't version code so much as packages. Because of the dependency  
> issues in Squeak, packages are either really big, or a "small"  
> change touches a lot of them. Either way, it means moving a lot  
> more data and doing more work to update image than what is required  
> for a change set. In practice, that makes it too slow everyday  
> workflow.
>
> MC2 actually versions code, so it has a lot more flexibility. It  
> would be possible, for example, to create an update stream of  
> "versioned changesets" that wouldn't carry too much overhead  
> compared to the classical update stream.

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

> 1b - create simple mirrors browser for more comfortable work
> 1c - create some fixes like WideString problems with condesing of
> changes etc.
> 2a - clean the kernel
> 2b - merge SUnit and relevant test
> 2c - create new important tests
> 3 - test the kernel image
> 4 - load everything back to create basic image. Don't create packages,
> just simply load new classes and methods and initialize it in the right
> order.
>
> (Task with the same number can be done in parallel)
>
> Then we will have nice UI independent kernel image and perfect
> referential material for next packaging effort.
>
> Then we can do the same process with next packages like network support,
> compression etc. Separate, load everything back.  It will be the set of
> small steps but with every one we will get the next clean package with
> the defined relation to the kernel and prerequisites.
>
> Just an idea. I think that it's doable. If we reached the state when we
> have consistent UI-less kernel image, why don't continue? The packaging
> "from top" and standard Squeak development and fixing can still continue
> because with every step we will have full image. So, what about to
> establisth a team for that?
>
> If we will have kernel image, the set of "primitive" packages like
> network, compression, UI independent MC and one big package "the rest of
> Squeak", we can mark it as Squeak 3.10 and then begin with version 4.0 -
> adopt many Spoon ideas, change VM and image format etc.
>
> -- Pavel

>
>> I wonder why Pavel don't say he could build a basic console with  
>> no MVC and
>> no Morphic.
>>
> I was on an official trip
>> I prefer use his old 3.7 kernel and not his new 3.9 , but is my  
>> taste.
>> Others could start from his newer.
>>
>
> There's no conceptual difference between kernel image for Squeak  
> 3.7 and Squeak 3.9, but Squeak 3.9 includes m17n and some other  
> code that makes this image much bigger. Kernel image form Squeak  
> 3.7 is perfect starting point for some kind of applications like  
> PocketPC games. Shrinking operations in kernel image for Squeak 3.9  
> are less destructive and this image is definitely better in many ways.
>
>> 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)
>>
> From my point of view, the best next progress can be:
> 1a - take the kernel image for Squeak 3.9 and merge all relevant  
> fixes since 6719
> 1b - create simple mirrors browser for more comfortable work
> 1c - create some fixes like WideString problems with condesing of  
> changes etc.
> 2a - clean the kernel
> 2b - merge SUnit and relevant test
> 2c - create new important tests
> 3 - test the kernel image
> 4 - load everything back to create basic image. Don't create  
> packages, just simply load new classes and methods and initialize  
> it in the right order.
>
> (Task with the same number can be done in parallel)
>
> Then we will have nice UI independent kernel image and perfect  
> referential material for next packaging effort.
>
> Then we can do the same process with next packages like network  
> support, compression etc. Separate, load everything back.  It will  
> be the set of small steps but with every one we will get the next  
> clean package with the defined relation to the kernel and  
> prerequisites.
>
> Just an idea. I think that it's doable. If we reached the state  
> when we have consistent UI-less kernel image, why don't continue?  
> The packaging "from top" and standard Squeak development and fixing  
> can still continue because with every step we will have full image.  
> So, what about to establisth a team for that?
>
> If we will have kernel image, the set of "primitive" packages like  
> network, compression, UI independent MC and one big package "the  
> rest of Squeak", we can mark it as Squeak 3.10 and then begin with  
> version 4.0 - adopt many Spoon ideas, change VM and image format etc.
>
> -- Pavel
>

>> 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'?

> 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
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.6.1/343 - Release Date: 5/18/2006
>
>

> Hi Ralph
>
> Improving design:
> ------------------------------
> One of the problems is that Squeak did much of its growth without any
> explicit package system. As a side effect, these systems usually enforce
> a-cyclic dependencies. Cyclic dependencies (considering just
> compilation-time-obvious dependencies, like a method in one class refering
> to a parent) are rampant in Squeak (see references to Morph), making it
> difficult to decompose.
>
> I wrote some code to aid finding, reducing and keeping down the incidence
> of such dependencies, called MudPie[1] (available from SqueakMap, I don't
> guarantee it works 3.9, but will if there's interest). DanI wrote some
> other modularization aid code. Some people have looked at these efforts,
> for example Juan, and tried to use them - I'll let them speak about their
> usefulness and/or problems. I would call neither tools, since they didn't
> include a real UI and such, which is sufficient cause for them to never
> have become widely used.
>
> Package system:
> --------------------------
> I believe that the management of the code of Squeak in tool supported
> packages is a critical component of any solution - this is the only way to
> keep the boundaries up to date. So the existance of MC exists makes this
> task somewhat feasible, but there have been various problems with its use
> to manage the whole image.
>
> - Performance (loading updates to the image using MC is much slower than
> loading changesets).
> - System changes (like introducing Traits) require going through various
> intermediate stages, but MC itself only model merging the code in order to
> reach the final stage to be loaded.
> - Workflow:
> -- Support for cherry picking is very basic in current MC (which MC2
> should improve).
> -- MC is quite workflow agnostic, but maintaining Squeak does require some
> workflow (people write fixes, other people merge them), and maintaining it
> as a set of packages requires even more of it (coordination of entry of
> package changes into the official release). Right now we use a combination
> of SqueakSource, Mantis, and email, glued together by (what seems to me
> like) lots of overhead.
>
>
> Daniel Vainsencher
> [1] listed in
> http://www.informatik.uni-trier.de/~ley/db/journals/cl/cl30.html
>> 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
>>
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.6.1/344 - Release Date: 5/19/2006
>
>

> Hello Ralph,
>
> I am the guy who tried to split Morphic in smaller packages that  
> could be easily unloaded.
> I failed. I did split Morphic in 3 big packages and a few small  
> ones, as you can see in Squeak 3.9. That took some work, but it can  
> be done. The big problem is that Etoys was not designed as a  
> separate package from the rest of the image. Writing Etoys impacted  
> everywhere. Therefore we have tons dependencies on it absolutely  
> everywhere. The same happens with Projects, Morphic and lots of  
> other "optional" functionality.

> I wanted something better: To redesign those dependencies in such a  
> way that just unloading the Etoys package would leave everything  
> working, and to allow re-loading it back. This is easy on small  
> examples, but an inmense amount of work with something like Etoys  
> in Squeak 3.9. Added to this were the difficulties in publishing my  
> stuff. This kind of changes generates new versions of almost all  
> the packages in Squeak all the time, conflicting with any other  
> thing someone could be working on, and giving a very hard time to  
> MC. So despite all the help Stef gave me, I finally abandoned the  
> idea.
>
> I hope to be of some help. BTW, let me thank you. Some of your  
> wrintings were really important when I took my first OOP course at  
> the university.
>
> Regards,
> Juan Vuletich
>
> Ps:
> For anyone who can be interested, I'm redesigning Morphic as an  
> experiment. The image I'm working is a 3.7 with no Etoys, no  
> Projects and a lot of Morphic removed. The Morph hierarchy was  
> removed to OldMorph, and Morph is my new experiment. The TestMorph  
> class is what I use to play there. It is available at http://
> www.sinectis.com.ar/u/jmvuletich/NewMorphic13.zip . Warning: This  
> is really early and primitive. If anyone wants more details, I'll  
> send them.

>
> ----- Original Message ----- From: "Ralph Johnson"  
> <[hidden email]>
> To: "The general-purpose Squeak developers list" <squeak-
> [hidden email]>
> Sent: Friday, May 19, 2006 9:20 AM
> Subject: Re: Whither Squeak?
>
>
>> 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
>>
>>
>>
>> --
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.1.392 / Virus Database: 268.6.1/343 - Release Date:  
>> 5/18/2006
>>
>
>

>Hi Daniel,
>
>I used MudPie for splitting Morphic. As I said in another message, I
>failed at making Etoys and MorphicExtras easy to unload and load back.
>This is because for fixing the bad dependencies without needing two
>versions of many core methods (i.e. methods not in the package we are
>removing). Doing this carefully is way too much for me (and for anybody, I
>guess). Squeak is too big!
>
>My experience with MudPie was excellent. It is great for spotting those
>dependencies. It works great, and when I needed some help, or new
>features, Daniel helped me a lot, and implemented many of my suggestions.
>Thanks, Daniel! And I can say: MudPie does work in 3.9.
>
>The problem was not lack of tools like MudPie. I could think of a tool
>that could automate the generation of some of the code needed for removing
>dependencies. But I don't think that would be a good solution. The only
>way to clean code is by understanding it. So, to me the problem is: too
>much work, too little time.
>
>Cheers,
>Juan Vuletich
>
>----- Original Message ----- From: "Daniel Vainsencher"
><[hidden email]>
>To: "The general-purpose Squeak developers list"
><[hidden email]>
>Sent: Saturday, May 20, 2006 7:42 AM
>Subject: Re: Whither Squeak?
>
>
>>Hi Ralph
>>
>>Improving design:
>>------------------------------
>>One of the problems is that Squeak did much of its growth without any
>>explicit package system. As a side effect, these systems usually enforce
>>a-cyclic dependencies. Cyclic dependencies (considering just
>>compilation-time-obvious dependencies, like a method in one class
>>refering to a parent) are rampant in Squeak (see references to Morph),
>>making it difficult to decompose.
>>
>>I wrote some code to aid finding, reducing and keeping down the incidence
>>of such dependencies, called MudPie[1] (available from SqueakMap, I don't
>>guarantee it works 3.9, but will if there's interest). DanI wrote some
>>other modularization aid code. Some people have looked at these efforts,
>>for example Juan, and tried to use them - I'll let them speak about their
>>usefulness and/or problems. I would call neither tools, since they didn't
>>include a real UI and such, which is sufficient cause for them to never
>>have become widely used.
>>
>>Package system:
>>--------------------------
>>I believe that the management of the code of Squeak in tool supported
>>packages is a critical component of any solution - this is the only way
>>to keep the boundaries up to date. So the existance of MC exists makes
>>this task somewhat feasible, but there have been various problems with
>>its use to manage the whole image.
>>
>>- Performance (loading updates to the image using MC is much slower than
>>loading changesets).
>>- System changes (like introducing Traits) require going through various
>>intermediate stages, but MC itself only model merging the code in order
>>to reach the final stage to be loaded.
>>- Workflow:
>>-- Support for cherry picking is very basic in current MC (which MC2
>>should improve).
>>-- MC is quite workflow agnostic, but maintaining Squeak does require
>>some workflow (people write fixes, other people merge them), and
>>maintaining it as a set of packages requires even more of it
>>(coordination of entry of package changes into the official release).
>>Right now we use a combination of SqueakSource, Mantis, and email, glued
>>together by (what seems to me like) lots of overhead.
>>
>>
>>Daniel Vainsencher
>>[1] listed in
>>http://www.informatik.uni-trier.de/~ley/db/journals/cl/cl30.html
>>>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
>>
>>
>>
>>
>>
>>--
>>No virus found in this incoming message.
>>Checked by AVG Free Edition.
>>Version: 7.1.392 / Virus Database: 268.6.1/344 - Release Date: 5/19/2006
>>
>

>
> Cheers,
>
> Alan
>
> ----------
>
> At 04:36 AM 5/23/2006, Juan Vuletich wrote:
>> Hi Daniel,
>>
>> I used MudPie for splitting Morphic. As I said in another message,  
>> I failed at making Etoys and MorphicExtras easy to unload and load  
>> back. This is because for fixing the bad dependencies without  
>> needing two versions of many core methods (i.e. methods not in the  
>> package we are removing). Doing this carefully is way too much for  
>> me (and for anybody, I guess). Squeak is too big!
>>
>> My experience with MudPie was excellent. It is great for spotting  
>> those dependencies. It works great, and when I needed some help,  
>> or new features, Daniel helped me a lot, and implemented many of  
>> my suggestions. Thanks, Daniel! And I can say: MudPie does work in  
>> 3.9.
>>
>> The problem was not lack of tools like MudPie. I could think of a  
>> tool that could automate the generation of some of the code needed  
>> for removing dependencies. But I don't think that would be a good  
>> solution. The only way to clean code is by understanding it. So,  
>> to me the problem is: too much work, too little time.
>>
>> Cheers,
>> Juan Vuletich
>>
>> ----- Original Message ----- From: "Daniel Vainsencher"  
>> <[hidden email]>
>> To: "The general-purpose Squeak developers list" <squeak-
>> [hidden email]>
>> Sent: Saturday, May 20, 2006 7:42 AM
>> Subject: Re: Whither Squeak?
>>
>>
>>> Hi Ralph
>>>
>>> Improving design:
>>> ------------------------------
>>> One of the problems is that Squeak did much of its growth without  
>>> any explicit package system. As a side effect, these systems  
>>> usually enforce a-cyclic dependencies. Cyclic dependencies  
>>> (considering just compilation-time-obvious dependencies, like a  
>>> method in one class refering to a parent) are rampant in Squeak  
>>> (see references to Morph), making it difficult to decompose.
>>>
>>> I wrote some code to aid finding, reducing and keeping down the  
>>> incidence of such dependencies, called MudPie[1] (available from  
>>> SqueakMap, I don't guarantee it works 3.9, but will if there's  
>>> interest). DanI wrote some other modularization aid code. Some  
>>> people have looked at these efforts, for example Juan, and tried  
>>> to use them - I'll let them speak about their usefulness and/or  
>>> problems. I would call neither tools, since they didn't include a  
>>> real UI and such, which is sufficient cause for them to never  
>>> have become widely used.
>>>
>>> Package system:
>>> --------------------------
>>> I believe that the management of the code of Squeak in tool  
>>> supported packages is a critical component of any solution - this  
>>> is the only way to keep the boundaries up to date. So the  
>>> existance of MC exists makes this task somewhat feasible, but  
>>> there have been various problems with its use to manage the whole  
>>> image.
>>>
>>> - Performance (loading updates to the image using MC is much  
>>> slower than loading changesets).
>>> - System changes (like introducing Traits) require going through  
>>> various intermediate stages, but MC itself only model merging the  
>>> code in order to reach the final stage to be loaded.
>>> - Workflow:
>>> -- Support for cherry picking is very basic in current MC (which  
>>> MC2 should improve).
>>> -- MC is quite workflow agnostic, but maintaining Squeak does  
>>> require some workflow (people write fixes, other people merge  
>>> them), and maintaining it as a set of packages requires even more  
>>> of it (coordination of entry of package changes into the official  
>>> release). Right now we use a combination of SqueakSource, Mantis,  
>>> and email, glued together by (what seems to me like) lots of  
>>> overhead.
>>>
>>>
>>> Daniel Vainsencher
>>> [1] listed in http://www.informatik.uni-trier.de/~ley/db/journals/ 
>>> cl/cl30.html
>>>> 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
>>>
>>>
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Free Edition.
>>> Version: 7.1.392 / Virus Database: 268.6.1/344 - Release Date:  
>>> 5/19/2006
>>>
>>
>
>
>
>

>On May 23, 2006, at 9:49 PM, Alan Kay wrote:
>
>>A good exercise (and very useful) would be just to build a new (and
>>much better) Etoys in your new Morphic. There is nothing sacred in
>>the current version of Etoys.
>
>Hi,
>
>having some fun Etoys experience myself (http://www.emergent.de/ etoys.html)
>I compiled a list (should I say Set ;-))
>  "Etoys: The good, the bad and the ugly"  - (to be criticized,
>prioritized and extended of course)
>
>Good:
>- Forces one to unify GUI + Model, which often does makes sense
>(think naked objects)
>- Allows visual programming using tiles
>- Comes with a rich set of toys
>- Is prototype based (good for exploring)
>- types variables by examples
>- holders/playfields are very powerful (iteration, inclusion...)
>- Generates Smalltalk Code in the background
>- Nice concept of halos
>- Connectors...
>- Quite transparent parallelism
>- Is translated to many languages
>- Net Morphs are coool
>- Nebraska (if it works) is nice too
>- Recorded sounds can be used as tiles
>- scripts allow parameters (though I seldom needed this)
>- Hardware Support (forgot the name, but this japanese people
>converting external measurements into sounds, which is in turn
>translated into sound...)
>- Is Used!
>- Comes with some simple sensors (overlaps, color sees...)
>- Constraints of Etoys allow some creativity
>- Kedama
>
>Bad:
>- Not easy for end user to extend with smalltalk code (e.g. some
>frustrated lisp programmer could not add midi to Etoys)
>- Limited set of events (will be better with Etoys2 ak Tweak)
>- Traces of turtles are pixels not objects (want to create some
>vector graphic with turtles...)
>- No notion of matrices ak 2D Fields
>- projects only storable as binaries (would be cool if commands would
>be logged en passant while creating a project...)
>- Squeak Plugin not widespread
>- some properties are not available (why can't I treat every player
>as a holder?)
>- Cannot extend with scripts which deliver booleans, always have to
>make a variable for that (maybe ok though)
>- Tiles create code, but code does not create tiles
>- Not yet available for 3d (croquet programming with Etoys would rock)
>- No bracketing of arithmetic expressions
>- preceding rules of Smalltalk and not of high school mathematics
>- Some tiles don't accept input (eg random...)
>- No debugger for etoys (difficult, but maybe fruitful)
>- "Genetive Programming" (first script any object, then say, that
>e.g. this script actually should affect the player at cursor...)
>- Connectors too much hidden
>- Strange organization of method categories (eg. misc...)
>- siblings can't be broken, copies can't be "siblinged"
>- No tasks, riddles with possible solutions online
>- no physics engine
>- Tweak, ak Etoys2 seems still to be slow
>- Projects in Projects are not publishable
>- Cells in Matrices should know about their neighbors
>- No use of midi
>- maybe Kedama could be integrated better
>
>Ugly:
>
>- mangling of EToys code everywhere in Squeak (though I strongly
>favor further inclusion of "the best etoys currently available" in
>the kitchen sink image
>
>Ok, got that of the list now...
>
>Cheers,
>
>Markus
>
>
>>
>>Cheers,
>>
>>Alan
>>
>>----------
>>
>>At 04:36 AM 5/23/2006, Juan Vuletich wrote:
>>>Hi Daniel,
>>>
>>>I used MudPie for splitting Morphic. As I said in another message,
>>>I failed at making Etoys and MorphicExtras easy to unload and load
>>>back. This is because for fixing the bad dependencies without
>>>needing two versions of many core methods (i.e. methods not in the
>>>package we are removing). Doing this carefully is way too much for
>>>me (and for anybody, I guess). Squeak is too big!
>>>
>>>My experience with MudPie was excellent. It is great for spotting
>>>those dependencies. It works great, and when I needed some help,
>>>or new features, Daniel helped me a lot, and implemented many of
>>>my suggestions. Thanks, Daniel! And I can say: MudPie does work in
>>>3.9.
>>>
>>>The problem was not lack of tools like MudPie. I could think of a
>>>tool that could automate the generation of some of the code needed
>>>for removing dependencies. But I don't think that would be a good
>>>solution. The only way to clean code is by understanding it. So,
>>>to me the problem is: too much work, too little time.
>>>
>>>Cheers,
>>>Juan Vuletich
>>>
>>>----- Original Message ----- From: "Daniel Vainsencher"
>>><[hidden email]>
>>>To: "The general-purpose Squeak developers list" <squeak-
>>>[hidden email]>
>>>Sent: Saturday, May 20, 2006 7:42 AM
>>>Subject: Re: Whither Squeak?
>>>
>>>
>>>>Hi Ralph
>>>>
>>>>Improving design:
>>>>------------------------------
>>>>One of the problems is that Squeak did much of its growth without
>>>>any explicit package system. As a side effect, these systems
>>>>usually enforce a-cyclic dependencies. Cyclic dependencies
>>>>(considering just compilation-time-obvious dependencies, like a
>>>>method in one class refering to a parent) are rampant in Squeak
>>>>(see references to Morph), making it difficult to decompose.
>>>>
>>>>I wrote some code to aid finding, reducing and keeping down the
>>>>incidence of such dependencies, called MudPie[1] (available from
>>>>SqueakMap, I don't guarantee it works 3.9, but will if there's
>>>>interest). DanI wrote some other modularization aid code. Some
>>>>people have looked at these efforts, for example Juan, and tried
>>>>to use them - I'll let them speak about their usefulness and/or
>>>>problems. I would call neither tools, since they didn't include a
>>>>real UI and such, which is sufficient cause for them to never
>>>>have become widely used.
>>>>
>>>>Package system:
>>>>--------------------------
>>>>I believe that the management of the code of Squeak in tool
>>>>supported packages is a critical component of any solution - this
>>>>is the only way to keep the boundaries up to date. So the
>>>>existance of MC exists makes this task somewhat feasible, but
>>>>there have been various problems with its use to manage the whole
>>>>image.
>>>>
>>>>- Performance (loading updates to the image using MC is much
>>>>slower than loading changesets).
>>>>- System changes (like introducing Traits) require going through
>>>>various intermediate stages, but MC itself only model merging the
>>>>code in order to reach the final stage to be loaded.
>>>>- Workflow:
>>>>-- Support for cherry picking is very basic in current MC (which
>>>>MC2 should improve).
>>>>-- MC is quite workflow agnostic, but maintaining Squeak does
>>>>require some workflow (people write fixes, other people merge
>>>>them), and maintaining it as a set of packages requires even more
>>>>of it (coordination of entry of package changes into the official
>>>>release). Right now we use a combination of SqueakSource, Mantis,
>>>>and email, glued together by (what seems to me like) lots of
>>>>overhead.
>>>>
>>>>
>>>>Daniel Vainsencher
>>>>[1] listed in http://www.informatik.uni-trier.de/~ley/db/journals/ 
>>>>cl/cl30.html
>>>>>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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>No virus found in this incoming message.
>>>>Checked by AVG Free Edition.
>>>>Version: 7.1.392 / Virus Database: 268.6.1/344 - Release Date:
>>>>5/19/2006
>>
>>
>>