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 >>> >> > > > > _______________________________________________ Squeakland mailing list [hidden email] http://squeakland.org/mailman/listinfo/squeakland |
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" >>><[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 >> >> >> _______________________________________________ Squeakland mailing list [hidden email] http://squeakland.org/mailman/listinfo/squeakland |
Free forum by Nabble | Edit this page |