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" danielv@tx.technion.ac.il To: "The general-purpose Squeak developers list" <squeak- dev@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@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
Hi Markus --
Good list!
But a better way to look at Etoys is that it was supposed to be a subset of a more comprehensive system for all programmers (as comprehensive as Smalltalk but a more advanced set of ideas). So, if we were to make a better system and do a special children's interface for part of it, that would be a better way to deal with "bad and ugly".
Cheers,
Alan
At 05:16 PM 5/23/2006, Markus Gaelli wrote:
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" danielv@tx.technion.ac.il To: "The general-purpose Squeak developers list" <squeak- dev@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@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
squeakland@lists.squeakfoundation.org
-
Alan Kay -
Markus Gaelli