Whither Squeak?
Alan Kay
alan.kay at squeakland.org
Tue May 23 19:49:06 UTC 2006
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.
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"
><danielv at tx.technion.ac.il>
>To: "The general-purpose Squeak developers list"
><squeak-dev at lists.squeakfoundation.org>
>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 <cdegroot at gmail.com> 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
>>
>
More information about the Squeak-dev
mailing list
|