- Pharo-users - lists.pharo.org

Re: [Pharo-users] first draft of a pharo zen

by laurent laffont

On Tue, Aug 24, 2010 at 8:05 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > >>> > >>> * A system with robust abstractions that a single person can > understand > What about: * Easy to understand, easy to learn from, easy to fix Indeed I woud like to spread the idea that little is needed to contribute, don't need to be an expert guru. Community counts. Laurent. > Not a system that more than one person understands? > > ;-) > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Aug. 24, 2010

Re: [Pharo-users] first draft of a pharo zen

by Marcus Denker

>>> >>> * A system with robust abstractions that a single person can understand Not a system that more than one person understands? ;-) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Aug. 24, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

On 24 August 2010 16:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > we often use symbols for identity keys. > Now I was just dreaming. > I had a long discussion with my friend, who was learning smalltalk, where we argued about 'selector is not a symbol'. The difference between a bare string and symbol is uniqueness. Literally, a symbol is just a string, which having additional, implied semantics, that same symbolic strings refer to a single, unique object. (Another minor one is immutability). The difference between a symbol and selector is less significant. A simple example. Suppose you have two different classes, one Symbol, other is Selector. Now, suppose that compiler creating an instance of Symbol each time it sees following: self foo. where 'foo' is selector (and instance of Selector). but now, lets put it in another way: self perform: #foo. A #foo is, obviously a symbol, and must be an instance of Symbol class, isnt? So, in #perform: you must somehow convert a symbol into selector and then find the implementation of method with given selector. This obviously kills an idea of having distinction between selectors and symbols, because implementation of #perform: will be awfully slow and awkward. >>> Hi guys >>> >>> I'm thinking aloud... >>> I was wondering if we could not take advantage of a new class: Selector. >>> MethodDict would only contain selectors and not symbols. >>> >>> I remember that I talked about that with hernan. >>> >> >> Hmm.. i don't see obvious advantages. Do you? >> Most symbols (90% of cases), used as selectors, so it is likely that >> such refactoring will be nothing more, >> but just renaming the class :) >> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-users mailing list >>> Pharo-users(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig.

Aug. 24, 2010

Re: [Pharo-users] first draft of a pharo zen

by Marcin Tustin

Technically, functions/methods are polymorphic ;) On Tue, Aug 24, 2010 at 2:30 PM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > good! you liked the idea :-) > > I have a semantic problem with "Better small polymorphic classes than a > large ugly one". I understand that objects are polimorphic, not clases. > I think we should say something about smalltalk meta-circular property and > something about that everythings is an object... > For example: > > * We don't fear metaprogramming because it brings dinamism to live > * We love objects because objects are everything and everything is an > object > > or something like that :-) > > > On Tue, Aug 24, 2010 at 6:51 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Since some of you are newcomers to smalltalk or may be did not know the >> value of pharo core people >> here is a first draft I wrote this morning thinking about pharo >> >> http://code.google.com/p/pharo/wiki/PharoZen >> >> * Beauty in the code, beauty in the comments >> * Simplicity is beautiful >> * Communication is key >> * Classes structure our vocabulary >> * Messages are our vocabulary >> * Polymorphism is our esperanto >> * Better small polymorphic classes than a large ugly one >> * Tests are important but can be replaced >> * Abstraction and composition are our friends >> * Explicit is better than implicit >> * Magic only at the right place >> * Simple processes to support progress >> * One step at a time >> * There is no unimportant fix >> * Quality is a emerging property >> * A system with robust abstractions that a single person can understand >> >> Stef >> Please comment also on the wiki. >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 11 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > > -- Marcin Tustin Mobile: 07773787105 Office: 020 3400 3259

Aug. 24, 2010

Re: [Pharo-users] first draft of a pharo zen

by Hernan Wilkinson

good! you liked the idea :-) I have a semantic problem with "Better small polymorphic classes than a large ugly one". I understand that objects are polimorphic, not clases. I think we should say something about smalltalk meta-circular property and something about that everythings is an object... For example: * We don't fear metaprogramming because it brings dinamism to live * We love objects because objects are everything and everything is an object or something like that :-) On Tue, Aug 24, 2010 at 6:51 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Since some of you are newcomers to smalltalk or may be did not know the > value of pharo core people > here is a first draft I wrote this morning thinking about pharo > > http://code.google.com/p/pharo/wiki/PharoZen > > * Beauty in the code, beauty in the comments > * Simplicity is beautiful > * Communication is key > * Classes structure our vocabulary > * Messages are our vocabulary > * Polymorphism is our esperanto > * Better small polymorphic classes than a large ugly one > * Tests are important but can be replaced > * Abstraction and composition are our friends > * Explicit is better than implicit > * Magic only at the right place > * Simple processes to support progress > * One step at a time > * There is no unimportant fix > * Quality is a emerging property > * A system with robust abstractions that a single person can understand > > Stef > Please comment also on the wiki. > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 11 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Aug. 24, 2010

Re: [Pharo-users] first draft of a pharo zen

by StÃ©phane Ducasse

Fixed :) again a violent proof of my english illiteracy. ;D > On 24 August 2010 12:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Since some of you are newcomers to smalltalk or may be did not know the value of pharo core people >> here is a first draft I wrote this morning thinking about pharo >> >> http://code.google.com/p/pharo/wiki/PharoZen >> >> * Beauty in the code, beauty in the comments >> * Simplicity is beautiful >> * Communication is key >> * Classes structure our vocabulary >> * Messages are our vocabulary >> * Polymorphism is our esperanto >> * Better small polymorphic classes than a large ugly one > > This sounds wrong.. IDK, but i think a more correct form is following: > > Better a number of small polymorphic classes than a large ugly one > >> * Tests are important but can be replaced >> * Abstraction and composition are our friends >> * Explicit is better than implicit >> * Magic only at the right place >> * Simple processes to support progress >> * One step at a time >> * There is no unimportant fix >> * Quality is a emerging property >> * A system with robust abstractions that a single person can understand >> > > Amen :) > >> Stef >> Please comment also on the wiki. >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 24, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by StÃ©phane Ducasse

we often use symbols for identity keys. Now I was just dreaming. >> Hi guys >> >> I'm thinking aloud... >> I was wondering if we could not take advantage of a new class: Selector. >> MethodDict would only contain selectors and not symbols. >> >> I remember that I talked about that with hernan. >> > > Hmm.. i don't see obvious advantages. Do you? > Most symbols (90% of cases), used as selectors, so it is likely that > such refactoring will be nothing more, > but just renaming the class :) > >> Stef >> >> >> _______________________________________________ >> Pharo-users mailing list >> Pharo-users(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

Aug. 24, 2010

Re: [Pharo-users] first draft of a pharo zen

by Igor Stasenko

On 24 August 2010 12:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Since some of you are newcomers to smalltalk or may be did not know the value of pharo core people > here is a first draft I wrote this morning thinking about pharo > > http://code.google.com/p/pharo/wiki/PharoZen > > Â * Beauty in the code, beauty in the comments > Â * Simplicity is beautiful > Â * Communication is key > Â * Classes structure our vocabulary > Â * Messages are our vocabulary > Â * Polymorphism is our esperanto > Â * Better small polymorphic classes than a large ugly one This sounds wrong.. IDK, but i think a more correct form is following: Better a number of small polymorphic classes than a large ugly one > Â * Tests are important but can be replaced > Â * Abstraction and composition are our friends > Â * Explicit is better than implicit > Â * Magic only at the right place > Â * Simple processes to support progress > Â * One step at a time > Â * There is no unimportant fix > Â * Quality is a emerging property > Â * A system with robust abstractions that a single person can understand > Amen :) > Stef > Please comment Â also on the wiki. > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig.

Aug. 24, 2010

Re: [Pharo-users] funny idea Symbol vs. Selector

by Igor Stasenko

On 23 August 2010 23:26, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi guys > > I'm thinking aloud... > I was wondering if we could not take advantage of a new class: Selector. > MethodDict would only contain selectors and not symbols. > > I remember that I talked about that with hernan. > Hmm.. i don't see obvious advantages. Do you? Most symbols (90% of cases), used as selectors, so it is likely that such refactoring will be nothing more, but just renaming the class :) > Stef > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > -- Best regards, Igor Stasenko AKA sig.

Aug. 24, 2010

[Survey] Assess the cycles in your software

by Laval Jannik

Hi, A new reminder for our study. We need your help to finish the study. Thank you to all participants. Cheers, > >> >> On Jul 19, 2010, at 08:36 , Laval Jannik wrote: >> >>> Hi Pharoers, and Smalltalkers in general, >>> >>> Have you seen waited to assess the cycles in your software? Now you can :) >>> >>> We request some of you to perform an experiment using DSM to see your software package structure and to fix cycles between packages. Our tool shows dependencies between packages and highlight some bad dependencies generating structure cycles. It also helps to understand dependencies. >>> >>> Your goal is to fill a survey using our tool. >>> I prepared a mini-tutorial about DSM and eDSM. It can help you to understand the visualization tool. >>> >>> To ease the use of our tool, I loaded it in a PharoCore1.2. And there are two archives available: >>> - the first contains an image with our tool with a model of Pharo loaded in it, so you can play with our tool on pharo itself. It can be downloaded here: http://dl.dropbox.com/u/7739334/dsmWithPharo.zip. Pay attention, the image is slow. >>> - the second contains the same thing without the model of Pharo. Here, you have to load your code, then populate a moose model and use the tool. It can be downloaded here: http://dl.dropbox.com/u/7739334/dsmWithoutPharo.zip >>> The two archives contain the tutorial and the survey. If you are a pharo integrator, we suggest you to take the one with Pharo model loaded, else the other. >>> >>> To use our tool, load your tool in Pharo. Then do "MoosePanel open", and import your software in Moose by "import from Smalltalk image". When it is imported, select your project in the list on the left of MoosePanel, and select "all model packages" on the list on center. >>> >>> Then, you have two choices: >>> - you can scan all your project: right click on "all model packages" and do DSM. >>> - or select "all model packages" then select some packages in the next list and right click, do DSM. >>> >>> After that, you can perform the survey (with reading of the tutorial). We need your answers for the end of August. So, you have two months to do it. >>> >>> If you have any question, just let me know. >>> >>> Best regards, >>> Jannik. >>> >>> --- >>> Jannik Laval >>> PhD Student - Rmod Team - INRIA >>> Certified Project Management Associate (IPMA) >>> http://www.jannik-laval.eu >>> http://rmod.lille.inria.fr >>> --- >>> > --- Jannik Laval

Aug. 24, 2010