Embracing Projects
Locked
12
12
 
|
Folks -
I always felt that one of the least used "big ideas" in Squeak is that of projects. Projects are incredibly powerful but have often been severely misunderstood. A Project in Squeak can define an entire environment (MVC, Morphic, Tweak), it can be a modification to an existing environment, it can identify a set of tools to be used in some context and more. The progress that we've made with refactoring of class Project makes it feasible to illustrate the power of projects. If you install the attached change set in an updated trunk image, you will find a new type of project available - a GamesProject. When you choose this type of project you will notice that it downloads and installs the MorphicGames package that Edgar just announced (thanks Edgar!), sets up the environment with a set of games before launching into it. (note that I didn't go as far as setting up the menu bar with games, removing the tools, sealing the programmer facilities etc. but all of this is possible and should be considered for the various types of projects) And of course, when we ship the next image, we could actually include a number of such "proto projects" like the GamesProject - it takes a tiny amount of space but makes it very accessible and very visible from an user point of view. As a conseqence, we can hopefully ship the next Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and whatnot projects. Thoughts? Cheers, - Andreas |
GamesProject.st (2K) |
|
This is great news!
I have always liked projects but my earlier attempts of trying to separate them from images didn't go smooth and I had difficulty moving projects between images. (Anyone remember trying to save projects from within SqueakNews issues?) In hindsight most of them were due to lousy global variables or some complex relationships but even a smarter extraction process that can inform potential problems will go a long way. Mobilization of projects a la Squeakland but on a grander scale will greatly enhance the ability to make "the experience" of being in an object world much more attractive. Tansel On 26/11/2009, at 3:25 PM, Andreas Raab wrote: > Folks - > > I always felt that one of the least used "big ideas" in Squeak is > that of projects. Projects are incredibly powerful but have often > been severely misunderstood. A Project in Squeak can define an > entire environment (MVC, Morphic, Tweak), it can be a modification > to an existing environment, it can identify a set of tools to be > used in some context and more. > > The progress that we've made with refactoring of class Project makes > it feasible to illustrate the power of projects. If you install the > attached change set in an updated trunk image, you will find a new > type of project available - a GamesProject. When you choose this > type of project you will notice that it downloads and installs the > MorphicGames package that Edgar just announced (thanks Edgar!), sets > up the environment with a set of games before launching into it. > (note that I didn't go as far as setting up the menu bar with games, > removing the tools, sealing the programmer facilities etc. but all > of this is possible and should be considered for the various types > of projects) > > And of course, when we ship the next image, we could actually > include a number of such "proto projects" like the GamesProject - it > takes a tiny amount of space but makes it very accessible and very > visible from an user point of view. As a conseqence, we can > hopefully ship the next Squeak version with (proto-)Games, Etoys, > VMMaker, Seaside and whatnot projects. > > Thoughts? > > Cheers, > - Andreas > > <GamesProject.st> |
|
|
Hi Tansel -
Nice to hear from you! This little demo is obviously not complete by any means :-) In the longer term, what I am imagining is more along the lines of projects storing their version and their contents and then (upon loading the project) that project first fetching the 'right' version of the code and afterwards loading its contents. This should work quite well assuming that the underpinnings (basic Squeak version etc) don't change. But even then, just recording that this project was saved with version x.y and may have issue when loaded into version x.z goes a very long way. Cheers, - Andreas Tansel Ersavas wrote: > This is great news! > > I have always liked projects but my earlier attempts of trying to > separate them from images didn't go smooth and I had difficulty moving > projects between images. (Anyone remember trying to save projects from > within SqueakNews issues?) In hindsight most of them were due to lousy > global variables or some complex relationships but even a smarter > extraction process that can inform potential problems will go a long > way. Mobilization of projects a la Squeakland but on a grander scale > will greatly enhance the ability to make "the experience" of being in an > object world much more attractive. > > Tansel > > > On 26/11/2009, at 3:25 PM, Andreas Raab wrote: > >> Folks - >> >> I always felt that one of the least used "big ideas" in Squeak is that >> of projects. Projects are incredibly powerful but have often been >> severely misunderstood. A Project in Squeak can define an entire >> environment (MVC, Morphic, Tweak), it can be a modification to an >> existing environment, it can identify a set of tools to be used in >> some context and more. >> >> The progress that we've made with refactoring of class Project makes >> it feasible to illustrate the power of projects. If you install the >> attached change set in an updated trunk image, you will find a new >> type of project available - a GamesProject. When you choose this type >> of project you will notice that it downloads and installs the >> MorphicGames package that Edgar just announced (thanks Edgar!), sets >> up the environment with a set of games before launching into it. (note >> that I didn't go as far as setting up the menu bar with games, >> removing the tools, sealing the programmer facilities etc. but all of >> this is possible and should be considered for the various types of >> projects) >> >> And of course, when we ship the next image, we could actually include >> a number of such "proto projects" like the GamesProject - it takes a >> tiny amount of space but makes it very accessible and very visible >> from an user point of view. As a conseqence, we can hopefully ship the >> next Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and >> whatnot projects. >> >> Thoughts? >> >> Cheers, >> - Andreas >> >> <GamesProject.st> > > > |
|
|
In reply to this post by Andreas.Raab
Hi Andreas,
AR> I always felt that one of the least used "big ideas" in Squeak is that AR> of projects. Projects are incredibly powerful but have often been AR> Thoughts? great! I use them all the time. Having a visual memory and being an occasional Squeak programmer it helps a lot to return to an environment which is readily set up for many aspects of the work. (35 and 17 instances of Project in my current images). I just saw that you made a change so that projects are automatically entered when created. Can't try that right now. My own workflow is to create a project, colour it, place it and maybe even create the next project before entering it. Cheers, Herbert mailto:[hidden email] |
|
|
In reply to this post by Andreas.Raab
Guilty! I use projects a lot to organise my work and like Herbert
typically layout several before entering one. I was aware of some sort of "fence" mechanism but always neglected to look deeper because that side of projects seemed to be getting increasingly abandoned. Very happy to see them now getting some love :-) From my POV it would great to have more tools for managing projects, especially in a hierarchy. I remember doing something for Etoys a year or two back so I will dig it out sometime and see if it is still relevant. -D Andreas Raab wrote: > Folks - > > I always felt that one of the least used "big ideas" in Squeak is that > of projects. Projects are incredibly powerful but have often been > severely misunderstood. A Project in Squeak can define an entire > environment (MVC, Morphic, Tweak), it can be a modification to an > existing environment, it can identify a set of tools to be used in some > context and more. > > The progress that we've made with refactoring of class Project makes it > feasible to illustrate the power of projects. If you install the > attached change set in an updated trunk image, you will find a new type > of project available - a GamesProject. When you choose this type of > project you will notice that it downloads and installs the MorphicGames > package that Edgar just announced (thanks Edgar!), sets up the > environment with a set of games before launching into it. (note that I > didn't go as far as setting up the menu bar with games, removing the > tools, sealing the programmer facilities etc. but all of this is > possible and should be considered for the various types of projects) > > And of course, when we ship the next image, we could actually include a > number of such "proto projects" like the GamesProject - it takes a tiny > amount of space but makes it very accessible and very visible from an > user point of view. As a conseqence, we can hopefully ship the next > Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and whatnot > projects. > > Thoughts? > > Cheers, > - Andreas > > > ------------------------------------------------------------------------ > > |
|
|
In reply to this post by Andreas.Raab
Hi Andreas,
I'd buy it immediately. Is there a tutorial somewhere that illustrates how to use these facilities? Best, Michael |
|
|
In reply to this post by Andreas.Raab
On Wed, Nov 25, 2009 at 08:25:39PM -0800, Andreas Raab wrote:
> > The progress that we've made with refactoring of class Project makes it > feasible to illustrate the power of projects. If you install the > attached change set in an updated trunk image, you will find a new type > of project available - a GamesProject. When you choose this type of > project you will notice that it downloads and installs the MorphicGames > package that Edgar just announced (thanks Edgar!) Wow, I had completely forgotten just how bad I am at playing chess. Thanks for reminding me Edgar! This works nicely, and an EToysProject seems like another good thing to have. The EToys folks are also keen to get DrGeo integrated into that environment, and perhaps DrGeo warrants a project type in its own right. Dave |
|
|
In reply to this post by Michael Haupt-3
Michael Haupt wrote:
> I'd buy it immediately. Is there a tutorial somewhere that illustrates > how to use these facilities? Not much at this point, partly because there really isn't much to it (yet). The GamesProject is split into three parts: The installation, the standard Morphic project setup and the custom Games setup. In the installation (GamesProject>>install) we detect whether MorphicGames are installed and if not, download and install it (this is pretty adhoc). The default Morphic setup is simply setting up the project like any other project (default background, menu bar etc) - there is plenty of stuff that's still missing here, for example having the ability to customize the menu bar (you could conceivably do that in the custom setup step but then you'd be creating some of these twice). Lastly, the custom setup (GamesProject>>setupProject:) should really (as the comment says) live inside the MorphicGames package so that it can be updated when the Games package gets updated. It can do whatever it wants with the Morphic world, in our case just adding a few thumbnails to launch the game but it could also open some of them by default etc. Lotsa room for fun stuff. Personally speaking, the biggest outstanding issue with projects (which will start biting us really soon now) is persistence. You can save one of these GamesProjects (whoopsie. or maybe not. it just blew up for me with something that looks like it might be crlf related) but the issue is that the way projects are persisted makes it difficult to ensure the proper dependencies are met (i.e., this needs to be loaded into a GamesProject which already implies that the MorphicGames package will be present etc). And ImageSegments are good for certain things, but as a general purpose long-term persistence mechanism they suck. Simply because by their very nature they can't store abstract descriptions but only the bits of the current implementation used. And if you've ever persisted stuff that you wanted to be able to load a year from now in the face of active development you know the latter is a recipe for disaster. Anyway, that's where we are now. It's a starting point, not the end of the story. Cheers, - Andreas |
|
|
In reply to this post by David T. Lewis
I love this idea of a proto-project, that contains only the knowledge
needed to load things as complex as eToys into an image from the internet (or the disk?.) I use projects like crazy. I like to keep the top project pristine for some reason, so I just add a project to it and do all of my work in sub-projects of that. I would very much like to see better support for filing out projects full of objects and then filing them back into other images (not the same image.) This would make moving from one image to the next less painful. On Thu, Nov 26, 2009 at 8:38 AM, David T. Lewis <[hidden email]> wrote: > On Wed, Nov 25, 2009 at 08:25:39PM -0800, Andreas Raab wrote: >> >> The progress that we've made with refactoring of class Project makes it >> feasible to illustrate the power of projects. If you install the >> attached change set in an updated trunk image, you will find a new type >> of project available - a GamesProject. When you choose this type of >> project you will notice that it downloads and installs the MorphicGames >> package that Edgar just announced (thanks Edgar!) > > Wow, I had completely forgotten just how bad I am at playing chess. > Thanks for reminding me Edgar! > > This works nicely, and an EToysProject seems like another good thing > to have. The EToys folks are also keen to get DrGeo integrated into > that environment, and perhaps DrGeo warrants a project type in its own > right. > > Dave > > > -- Ron |
|
|
In reply to this post by Tansel Ersavas
FWIW -
I, too, am very happy to hear of projects being revisited. It always seemed to me that a Project was *just* a sub-Squeak. It's so with regard to Display area, it's so with regard to changes and (when the planets are lined up right) it can even be so with regard to an ImageSegment as part of the image. As Tansel points out, global variables and similar referential issues were the bane of the image segments. I (and Ted K) worked hard to deal with this problem back in the day, and I tried redefining Smalltalk as a Project-local Dictionary ("Environment") linked to the dictionary of its parent project. I don't know if this kind of inheritance structure is best in general, but at one time the reorganizeEverything method actually restructured the whole system this way, introduced a name-space approach to cross-module references, and kept running afterwards. The motivation (which began with the need to support Alan's mondo 200M images with 100 projects) was to keep the "kernel" image small, and to load and unload projects as swapping units. But the same unit served well to divest the image of big categories like VM construction, EToys, etc (though this was just two levels, not deep). The one thing I did differently from most of the other namespace proposals was to make global references be (capitalized) messages to the module dictionaries. This had the nice property that, if you worked on a new Stream package called MyStreams, then simply executing, eg, OriginalStreams := KernelStreams. KernelStreams := MyStreams. Would cause all code to start using the new streams, and it could all be reverted atomically with KernelStreams := OriginalStreams One could do this on a project-local basis too, allowing for multiple coexisting versions. [There are other reasons for having global references be messages] Henrik Gedenryd picked up this work and carried it quite a bit farther into the system and sadly things got a bit too incompatible. It was a big frustration for me (and for him++) that we never managed to pull this off to completion. I wouldn't want to interfere with Andreas's nice suggestion. But I do think there's much more possible if anyone gets interested. Don't know if Spoon uses the synergy of projects as modules. - Dan ----------------------------- >This is great news! > >I have always liked projects but my earlier attempts of trying to separate them from images didn't go smooth and I had difficulty moving projects between images. (Anyone remember trying to save projects from within SqueakNews issues?) In hindsight most of them were due to lousy global variables or some complex relationships but even a smarter extraction process that can inform potential problems will go a long way. Mobilization of projects a la Squeakland but on a grander scale will greatly enhance the ability to make "the experience" of being in an object world much more attractive. > >Tansel > > >On 26/11/2009, at 3:25 PM, Andreas Raab wrote: > >>Folks - >> >>I always felt that one of the least used "big ideas" in Squeak is that of projects. Projects are incredibly powerful but have often been severely misunderstood. A Project in Squeak can define an entire environment (MVC, Morphic, Tweak), it can be a modification to an existing environment, it can identify a set of tools to be used in some context and more. >> >>The progress that we've made with refactoring of class Project makes it feasible to illustrate the power of projects. If you install the attached change set in an updated trunk image, you will find a new type of project available - a GamesProject. When you choose this type of project you will notice that it downloads and installs the MorphicGames package that Edgar just announced (thanks Edgar!), sets up the environment with a set of games before launching into it. (note that I didn't go as far as setting up the menu bar with games, removing the tools, sealing the programmer facilities etc. but all of this is possible and should be considered for the various types of projects) >> >>And of course, when we ship the next image, we could actually include a number of such "proto projects" like the GamesProject - it takes a tiny amount of space but makes it very accessible and very visible from an user point of view. As a conseqence, we can hopefully ship the next Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and whatnot projects. >> >>Thoughts? >> >>Cheers, >> - Andreas >> >><GamesProject.st> |
|
|
In reply to this post by Tansel Ersavas
2009/12/3 Dan Ingalls <[hidden email]>:
> FWIW - > > I, too, am very happy to hear of projects being revisited. It always seemed to me that a Project was *just* a sub-Squeak. It's so with regard to Display area, it's so with regard to changes and (when the planets are lined up right) it can even be so with regard to an ImageSegment as part of the image. > > As Tansel points out, global variables and similar referential issues were the bane of the image segments. I (and Ted K) worked hard to deal with this problem back in the day, and I tried redefining Smalltalk as a Project-local Dictionary ("Environment") linked to the dictionary of its parent project. I don't know if this kind of inheritance structure is best in general, but at one time the reorganizeEverything method actually restructured the whole system this way, introduced a name-space approach to cross-module references, and kept running afterwards. > > The motivation (which began with the need to support Alan's mondo 200M images with 100 projects) was to keep the "kernel" image small, and to load and unload projects as swapping units. But the same unit served well to divest the image of big categories like VM construction, EToys, etc (though this was just two levels, not deep). The one thing I did differently from most of the other namespace proposals was to make global references be (capitalized) messages to the module dictionaries. This had the nice property that, if you worked on a new Stream package called MyStreams, then simply executing, eg, > OriginalStreams := KernelStreams. > KernelStreams := MyStreams. > Would cause all code to start using the new streams, and it could all be reverted atomically with > KernelStreams := OriginalStreams > One could do this on a project-local basis too, allowing for multiple coexisting versions. > [There are other reasons for having global references be messages] > > Henrik Gedenryd picked up this work and carried it quite a bit farther into the system and sadly things got a bit too incompatible. It was a big frustration for me (and for him++) that we never managed to pull this off to completion. > > I wouldn't want to interfere with Andreas's nice suggestion. But I do think there's much more possible if anyone gets interested. Don't know if Spoon uses the synergy of projects as modules. > My very first impression, when i started discovering Squeak & Projects was exactly as you describing: - a separate, isolated object & name space, which can be easily plugged in/out from system. I expected that any changes i doing in one project can't be seen by others. Sure , later i found that its not quite as it supposed to be. To my perception, a Project should be a wrapper or something built on top of 'module' in modularized system. What i mean, that modules should be more basic building brick & should serve towards automation (loading/unloading/interfacing with other parts of system), but not UI/Morphic at first place as Project(s) do. > - Dan > ----------------------------- > >>This is great news! >> >>I have always liked projects but my earlier attempts of trying to separate them from images didn't go smooth and I had difficulty moving projects between images. (Anyone remember trying to save projects from within SqueakNews issues?) In hindsight most of them were due to lousy global variables or some complex relationships but even a smarter extraction process that can inform potential problems will go a long way. Mobilization of projects a la Squeakland but on a grander scale will greatly enhance the ability to make "the experience" of being in an object world much more attractive. >> >>Tansel >> >> >>On 26/11/2009, at 3:25 PM, Andreas Raab wrote: >> >>>Folks - >>> >>>I always felt that one of the least used "big ideas" in Squeak is that of projects. Projects are incredibly powerful but have often been severely misunderstood. A Project in Squeak can define an entire environment (MVC, Morphic, Tweak), it can be a modification to an existing environment, it can identify a set of tools to be used in some context and more. >>> >>>The progress that we've made with refactoring of class Project makes it feasible to illustrate the power of projects. If you install the attached change set in an updated trunk image, you will find a new type of project available - a GamesProject. When you choose this type of project you will notice that it downloads and installs the MorphicGames package that Edgar just announced (thanks Edgar!), sets up the environment with a set of games before launching into it. (note that I didn't go as far as setting up the menu bar with games, removing the tools, sealing the programmer facilities etc. but all of this is possible and should be considered for the various types of projects) >>> >>>And of course, when we ship the next image, we could actually include a number of such "proto projects" like the GamesProject - it takes a tiny amount of space but makes it very accessible and very visible from an user point of view. As a conseqence, we can hopefully ship the next Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and whatnot projects. >>> >>>Thoughts? >>> >>>Cheers, >>> - Andreas >>> >>><GamesProject.st> > > > -- Best regards, Igor Stasenko AKA sig. |
Universal Composition and modules etc (was Re: Embracing Projects)
|
|
In reply to this post by Dan Ingalls
Hi Dan!
Hope Argentina was nice! Dan Ingalls wrote: > Henrik Gedenryd picked up this work and carried it quite a bit farther into the system and sadly things got a bit too > incompatible. It was a big frustration for me (and for him++) that we never managed to pull this off to completion. While "almost" on the subject - did Henrik ever demo his "universal composition" work to you and his refactored implementation of BitBlt which IIRC turned into a very clean pipeline-ish thing with no performance penalty (since the runtime code turned more or less the same)? We shared a hotel room at that OOPSLA and I recall he wanted to show it to you - but I am not sure he ever got the time. Since his "universal composition" stuff sounded quite intriguing at the time I was just curious to hear if you saw it and have any thoughts on it. And yes, the Modules 3.3 branch in Squeak history is generally a sad chapter. I hope, perhaps soon (now that we are again gathering speed to actually move Squeak forward into the future) - we can revisit those ideas and blend them with thoughts in Newspeak etc to see if we can eventually get something that "solves" the whole dependency/modules/packages/namespace arena. It would be awesome if we could take at least *some* step in this direction. Lesson learned though: the environment and tools MUST follow at the same time. I also note that the same lesson has been re-learned regarding Traits... regards, Göran PS. Note to others - Henrik Gedenryd is unfortunately not with us anymore, he has passed away, unfortunately all too young. |
Traits (was Re: Universal Composition and modules)
|
|
Göran Krampe a écrit :
> Lesson learned though: the environment and tools MUST follow at the same > time. > > I also note that the same lesson has been re-learned regarding Traits... If I remember correctly, Andreas once demonstrated in this list a much simpler implementation of Traits. What about getting rid of the current mostly unused (AFAIK) implementation and replacing it with simpler Traits while having the tools follow ? Stef |
Re: Traits (was Re: Universal Composition and modules)
|
|
On Thu, Dec 03, 2009 at 12:53:47PM +0100, St?phane Rollandin wrote:
> G?ran Krampe a ?crit : > >Lesson learned though: the environment and tools MUST follow at the same > >time. > > > >I also note that the same lesson has been re-learned regarding Traits... > > If I remember correctly, Andreas once demonstrated in this list a much > simpler implementation of Traits. What about getting rid of the current > mostly unused (AFAIK) implementation and replacing it with simpler > Traits while having the tools follow ? What problem are you trying to solve? If we believe that the problem is lack of tools integration, then we should fix that problem. For whatever reason, nobody seems to care enough about this to do the tools integration work. It is hard to imagine that adding a different (and probably incompatible) implementation of traits would cause the tools integration to happen any faster. Traits seems to be an interesting experiment, and the folks who care most about it are now working on Pharo images. I think that's an excellent place for the experiment to proceed, and if it turns out to have any useful results then I'm sure there will be interest in updating Squeak tools to take advantage. Meantime, maintaining the the current Traits in Squeak appears to be low effort, given that we adopt any bug fixes that arise from the Pharo work. Dave |
Re: Traits (was Re: Universal Composition and modules)
|
|
> What problem are you trying to solve?
well, I have several issues that would be nicely addressed by Traits. the problem I would like to see solved is that of usability of Traits in Squeak. I believe Traits are currently not really usable, by lack of system support (tools, etc.) > For whatever reason, nobody seems to care enough about this to do the > tools integration work. I guess the reason is that the Traits implementors have moved to another project, where they may or may not have better tool support in the near or far future. > It is hard to imagine that adding a different > (and probably incompatible) implementation of traits would cause the > tools integration to happen any faster. I'm not talking about adding an incompatible implementation, I just recalled that Andreas once said here that the current implementation is deeply flawed, overly complicated and could be *replaced* by a much better one. I may be wrong here, which is why I asked. Stef |
Re: Traits (was Re: Universal Composition and modules)
|
|
2009/12/3 Stéphane Rollandin <[hidden email]>
One issue with the current traits implementation is the cost/benefit ratio. Because it isn't used except in its own implementation it doesn't pay its way. It introduces lots of complexity and doesn't return functionality because it isn't used in the places where it could be. The most important place is the collection hierarchy where a trait-based implementation should in theory produce a much more flexible composable library. See Bill Cook's "Interfaces and specifications for the
Smalltalk-80 collection classes.", from "OOPSLA ’92,". I'm ignorant of the history but I've also read Andrew, Nathanael and Stéphane's "Applying Traits to the Smalltalk Collection Classes" so I don't know why we ended up with just traits applied to the traits implementation and lost traits applied to the collection hierarchy. I'd like to know why. My gut is that it might have broken too much older stuff. If this is right then IMO this is another strong argument for producing small kernels that can load modules. One could imagine a kernel that included traits applied to the collections into which one could load packages. The traits collections kernel and the old collections kernel could exist side-by-side and we could compare, provide migration tools for subclasses of old collections, etc. Another issue with traits is instance variable access. Newspeak throws away direct inst var access and only uses accessors so its mixins can add instance variables. So in some sense the Squeak traits implementation isn't radical enough. But throwing away inst var accessors really feels like a new language, or at least a new system, because it impacts so many things: at the implementation level the ClassBuilder can and should behave differently, the bytecode set should be different, a JIT should use copy-down, etc; at the class library level one can factor things very differently. To grapple with the kind of language evolution implied by traits and Newspeak I think we should be working on package-level refactoring that aims at being able to move packages between different languages. It would be great to back-port Vassili's native GUI from Newspeak. It would be great to migrate Andrew, Nathanael and Stéphane's collection classes to Newspeak (or as the Newspeak team is trying to migrate Strongtalk's collection classes). But doing this manually is IMO insane because its labour-intensive and error-prone. Yes, parts of any migration may require intervention in the form of hand-crafted rules for special cases but it can't be a first-order process. best, speaking in ignorance of Squeak's recent evolution, Eliot |
Re: Traits (was Re: Universal Composition and modules)
|
|
2009/12/3 Eliot Miranda <[hidden email]>:
> > > 2009/12/3 Stéphane Rollandin <[hidden email]> >>> >>> What problem are you trying to solve? >> >> well, I have several issues that would be nicely addressed by Traits. the >> problem I would like to see solved is that of usability of Traits in Squeak. >> I believe Traits are currently not really usable, by lack of system support >> (tools, etc.) >> >>> For whatever reason, nobody seems to care enough about this to do the >>> tools integration work. >> >> I guess the reason is that the Traits implementors have moved to another >> project, where they may or may not have better tool support in the near or >> far future. >> >>> It is hard to imagine that adding a different >>> (and probably incompatible) implementation of traits would cause the >>> tools integration to happen any faster. >> >> I'm not talking about adding an incompatible implementation, I just >> recalled that Andreas once said here that the current implementation is >> deeply flawed, overly complicated and could be *replaced* by a much better >> one. I may be wrong here, which is why I asked. >> >> Stef > > One issue with the current traits implementation is the cost/benefit ratio. > Because it isn't used except in its own implementation it doesn't pay its > way. It introduces lots of complexity and doesn't return functionality > because it isn't used in the places where it could be. The most important > place is the collection hierarchy where a trait-based implementation should > in theory produce a much more flexible composable library. See Bill > Cook's "Interfaces and specifications for the > > Smalltalk-80 collection classes.", from "OOPSLA ’92,". I'm ignorant of the > history but I've also read Andrew, Nathanael and Stéphane's "Applying Traits > to the Smalltalk Collection Classes" so I don't know why we ended up with > just traits applied to the traits implementation and lost traits applied to > the collection hierarchy. I'd like to know why. My gut is that it might > have broken too much older stuff. If this is right then IMO this is another > strong argument for producing small kernels that can load modules. One > could imagine a kernel that included traits applied to the collections into > which one could load packages. The traits collections kernel and the old > collections kernel could exist side-by-side and we could compare, provide > migration tools for subclasses of old collections, etc. > I agree that currently Traits is not widely adopted and used among developers (be it Collections or something else). I seen couple of times, people saying that it would be cool to use traits for rewriting the Collections classes, but to my knowledge, nobody started with it yet. But i don't agree that there is a bad cost/benefit ratio. I think that problem lies more in social plane (widely adopting & accepting new idea(s)) and only then in technical plane - i.e. maturity level (both implementation and tools). I think that traits has many things to offer to developers, in addition to smalltalk 'standard' as we know it. > Another issue with traits is instance variable access. Newspeak throws away > direct inst var access and only uses accessors so its mixins can add > instance variables. So in some sense the Squeak traits implementation isn't > radical enough. But throwing away inst var accessors really feels like a > new language, or at least a new system, because it impacts so many things: > at the implementation level the ClassBuilder can and should behave > differently, the bytecode set should be different, a JIT should use > copy-down, etc; at the class library level one can factor things very > differently. > There are some quite radical ideas concerning traits, which definitely will feel like a new language: - with introduction of stateful traits, one could completely eliminate the class inheritance, by replacing it with trait composition. > To grapple with the kind of language evolution implied by traits and > Newspeak I think we should be working on package-level refactoring that aims > at being able to move packages between different languages. It would be > great to back-port Vassili's native GUI from Newspeak. It would be great to > migrate Andrew, Nathanael and Stéphane's collection classes to Newspeak (or > as the Newspeak team is trying to migrate Strongtalk's collection classes). > But doing this manually is IMO insane because its labour-intensive and > error-prone. Yes, parts of any migration may require intervention in the > form of hand-crafted rules for special cases but it can't be a first-order > process. > > best, > > speaking in ignorance of Squeak's recent evolution, > ignorance is a blessing to learn something new, or a curse, if one don't wants to learn :) > Eliot > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Traits (was Re: Universal Composition and modules)
|
|
Igor: +1. I think the technical plane is in part a function of the
social plane. What Traits needs more than anything else is more documentation. Research papers are great, but some tutorials would be useful to newbies like me. FYI the paper in question mentioning the collections refactoring is here: http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf And the rest of the documentation is here: http://scg.unibe.ch/research/traits On Thu, Dec 3, 2009 at 11:39 AM, Igor Stasenko <[hidden email]> wrote: > 2009/12/3 Eliot Miranda <[hidden email]>: >> >> >> 2009/12/3 Stéphane Rollandin <[hidden email]> >>>> >>>> What problem are you trying to solve? >>> >>> well, I have several issues that would be nicely addressed by Traits. the >>> problem I would like to see solved is that of usability of Traits in Squeak. >>> I believe Traits are currently not really usable, by lack of system support >>> (tools, etc.) >>> >>>> For whatever reason, nobody seems to care enough about this to do the >>>> tools integration work. >>> >>> I guess the reason is that the Traits implementors have moved to another >>> project, where they may or may not have better tool support in the near or >>> far future. >>> >>>> It is hard to imagine that adding a different >>>> (and probably incompatible) implementation of traits would cause the >>>> tools integration to happen any faster. >>> >>> I'm not talking about adding an incompatible implementation, I just >>> recalled that Andreas once said here that the current implementation is >>> deeply flawed, overly complicated and could be *replaced* by a much better >>> one. I may be wrong here, which is why I asked. >>> >>> Stef >> >> One issue with the current traits implementation is the cost/benefit ratio. >> Because it isn't used except in its own implementation it doesn't pay its >> way. It introduces lots of complexity and doesn't return functionality >> because it isn't used in the places where it could be. The most important >> place is the collection hierarchy where a trait-based implementation should >> in theory produce a much more flexible composable library. See Bill >> Cook's "Interfaces and specifications for the >> >> Smalltalk-80 collection classes.", from "OOPSLA ’92,". I'm ignorant of the >> history but I've also read Andrew, Nathanael and Stéphane's "Applying Traits >> to the Smalltalk Collection Classes" so I don't know why we ended up with >> just traits applied to the traits implementation and lost traits applied to >> the collection hierarchy. I'd like to know why. My gut is that it might >> have broken too much older stuff. If this is right then IMO this is another >> strong argument for producing small kernels that can load modules. One >> could imagine a kernel that included traits applied to the collections into >> which one could load packages. The traits collections kernel and the old >> collections kernel could exist side-by-side and we could compare, provide >> migration tools for subclasses of old collections, etc. >> > > I agree that currently Traits is not widely adopted and used among > developers (be it Collections or something else). > I seen couple of times, people saying that it would be cool to use > traits for rewriting the Collections classes, but to my knowledge, > nobody started with it yet. > But i don't agree that there is a bad cost/benefit ratio. I think that > problem lies more in social plane (widely adopting & accepting new > idea(s)) and only then in technical plane - i.e. maturity level (both > implementation and tools). > I think that traits has many things to offer to developers, in > addition to smalltalk 'standard' as we know it. > >> Another issue with traits is instance variable access. Newspeak throws away >> direct inst var access and only uses accessors so its mixins can add >> instance variables. So in some sense the Squeak traits implementation isn't >> radical enough. But throwing away inst var accessors really feels like a >> new language, or at least a new system, because it impacts so many things: >> at the implementation level the ClassBuilder can and should behave >> differently, the bytecode set should be different, a JIT should use >> copy-down, etc; at the class library level one can factor things very >> differently. >> > > There are some quite radical ideas concerning traits, which definitely > will feel like a new language: > - with introduction of stateful traits, one could completely eliminate > the class inheritance, > by replacing it with trait composition. > >> To grapple with the kind of language evolution implied by traits and >> Newspeak I think we should be working on package-level refactoring that aims >> at being able to move packages between different languages. It would be >> great to back-port Vassili's native GUI from Newspeak. It would be great to >> migrate Andrew, Nathanael and Stéphane's collection classes to Newspeak (or >> as the Newspeak team is trying to migrate Strongtalk's collection classes). >> But doing this manually is IMO insane because its labour-intensive and >> error-prone. Yes, parts of any migration may require intervention in the >> form of hand-crafted rules for special cases but it can't be a first-order >> process. >> >> best, >> >> speaking in ignorance of Squeak's recent evolution, >> > > ignorance is a blessing to learn something new, or a curse, if one > don't wants to learn :) > >> Eliot >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > -- Ron |
Re: Traits (was Re: Universal Composition and modules)
|
|
Whoops, that paper just makes mention. Here's the detailed report
regarding collections: http://scg.unibe.ch/archive/papers/Blac03aTraitsHierarchy.pdf On Thu, Dec 3, 2009 at 12:21 PM, Ronald Spengler <[hidden email]> wrote: > Igor: +1. I think the technical plane is in part a function of the > social plane. What Traits needs more than anything else is more > documentation. Research papers are great, but some tutorials would be > useful to newbies like me. > > FYI the paper in question mentioning the collections refactoring is here: > > http://scg.unibe.ch/archive/papers/Scha02bTraits.pdf > > And the rest of the documentation is here: > > http://scg.unibe.ch/research/traits > > On Thu, Dec 3, 2009 at 11:39 AM, Igor Stasenko <[hidden email]> wrote: >> 2009/12/3 Eliot Miranda <[hidden email]>: >>> >>> >>> 2009/12/3 Stéphane Rollandin <[hidden email]> >>>>> >>>>> What problem are you trying to solve? >>>> >>>> well, I have several issues that would be nicely addressed by Traits. the >>>> problem I would like to see solved is that of usability of Traits in Squeak. >>>> I believe Traits are currently not really usable, by lack of system support >>>> (tools, etc.) >>>> >>>>> For whatever reason, nobody seems to care enough about this to do the >>>>> tools integration work. >>>> >>>> I guess the reason is that the Traits implementors have moved to another >>>> project, where they may or may not have better tool support in the near or >>>> far future. >>>> >>>>> It is hard to imagine that adding a different >>>>> (and probably incompatible) implementation of traits would cause the >>>>> tools integration to happen any faster. >>>> >>>> I'm not talking about adding an incompatible implementation, I just >>>> recalled that Andreas once said here that the current implementation is >>>> deeply flawed, overly complicated and could be *replaced* by a much better >>>> one. I may be wrong here, which is why I asked. >>>> >>>> Stef >>> >>> One issue with the current traits implementation is the cost/benefit ratio. >>> Because it isn't used except in its own implementation it doesn't pay its >>> way. It introduces lots of complexity and doesn't return functionality >>> because it isn't used in the places where it could be. The most important >>> place is the collection hierarchy where a trait-based implementation should >>> in theory produce a much more flexible composable library. See Bill >>> Cook's "Interfaces and specifications for the >>> >>> Smalltalk-80 collection classes.", from "OOPSLA ’92,". I'm ignorant of the >>> history but I've also read Andrew, Nathanael and Stéphane's "Applying Traits >>> to the Smalltalk Collection Classes" so I don't know why we ended up with >>> just traits applied to the traits implementation and lost traits applied to >>> the collection hierarchy. I'd like to know why. My gut is that it might >>> have broken too much older stuff. If this is right then IMO this is another >>> strong argument for producing small kernels that can load modules. One >>> could imagine a kernel that included traits applied to the collections into >>> which one could load packages. The traits collections kernel and the old >>> collections kernel could exist side-by-side and we could compare, provide >>> migration tools for subclasses of old collections, etc. >>> >> >> I agree that currently Traits is not widely adopted and used among >> developers (be it Collections or something else). >> I seen couple of times, people saying that it would be cool to use >> traits for rewriting the Collections classes, but to my knowledge, >> nobody started with it yet. >> But i don't agree that there is a bad cost/benefit ratio. I think that >> problem lies more in social plane (widely adopting & accepting new >> idea(s)) and only then in technical plane - i.e. maturity level (both >> implementation and tools). >> I think that traits has many things to offer to developers, in >> addition to smalltalk 'standard' as we know it. >> >>> Another issue with traits is instance variable access. Newspeak throws away >>> direct inst var access and only uses accessors so its mixins can add >>> instance variables. So in some sense the Squeak traits implementation isn't >>> radical enough. But throwing away inst var accessors really feels like a >>> new language, or at least a new system, because it impacts so many things: >>> at the implementation level the ClassBuilder can and should behave >>> differently, the bytecode set should be different, a JIT should use >>> copy-down, etc; at the class library level one can factor things very >>> differently. >>> >> >> There are some quite radical ideas concerning traits, which definitely >> will feel like a new language: >> - with introduction of stateful traits, one could completely eliminate >> the class inheritance, >> by replacing it with trait composition. >> >>> To grapple with the kind of language evolution implied by traits and >>> Newspeak I think we should be working on package-level refactoring that aims >>> at being able to move packages between different languages. It would be >>> great to back-port Vassili's native GUI from Newspeak. It would be great to >>> migrate Andrew, Nathanael and Stéphane's collection classes to Newspeak (or >>> as the Newspeak team is trying to migrate Strongtalk's collection classes). >>> But doing this manually is IMO insane because its labour-intensive and >>> error-prone. Yes, parts of any migration may require intervention in the >>> form of hand-crafted rules for special cases but it can't be a first-order >>> process. >>> >>> best, >>> >>> speaking in ignorance of Squeak's recent evolution, >>> >> >> ignorance is a blessing to learn something new, or a curse, if one >> don't wants to learn :) >> >>> Eliot >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > > > -- > Ron > -- Ron |
Re: Traits (was Re: Universal Composition and modules)
|
|
In reply to this post by Stéphane Rollandin
Stéphane Rollandin wrote:
> If I remember correctly, Andreas once demonstrated in this list a much > simpler implementation of Traits. What about getting rid of the current > mostly unused (AFAIK) implementation and replacing it with simpler > Traits while having the tools follow ? That's a *really* good idea, thanks for reminding me. It'll be such a relief to get rid of all of that needless complexity. Now where did I put that code... Cheers, - Andreas |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |