- Pharo-users - lists.pharo.org

The Pharo Advantage: what is it for you?

by phil＠highoctane.be

Hello, As part of the defense of a budget and technology choices, what would you guys list as a key advantage of using Pharo for creating software solutions? My current stack is: Pharo 2.0 Seaside 3 (including Seaside-REST) Magritte 3 Twitter Bootstrap + a couple of data storage stuff (DBXTalk, Phriak, Voyage) + STOMP + Amber if needed I've been test driving the whole stack for a while and even if there are some quirks, it looks like good enough for what I want to achieve. Now, my question: what is the Pharo advantage you would put forward vs other choices (like LAMP, Java, Rails etc). I am aware of what those could be but I am more looking for what makes you tick when using the technology (like: "it is fun to work with", "no more Java for me, due to ...", "speeds dev time by ...", "not NSA-backdoor-enabled") This is the kind of thing we should have in stock for helping the Consortium members get buy in from people giving a yes on budgets. Thanks in advance for your help! (BTW, I am going to use this on monday morning for defending our position on a significant project). Phil

Aug. 23, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Am 23.08.2013 um 09:34 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> Hi Norbert, >>> >>> It sounds like you want something like talents Talents http://scg.unibe.ch/research/bifrost/talents. >>> However, there is no running version on pharo 3.0 yet. >>> >>> I am not aware of work on object-specific traits, I could be wrong though. >>> >> you might be right. The way talents work is basically what I am asking for. I never got into depth with talents and thought it is much more than adjustment of behavior on per object base. I was hoping there are some easy things available to use in order to modify behavior lookup. I should have a look at talents. Thanks for the tip. > > would strategy not solve your problem? > Sure if I would have an actual problem I would use strategy to mitigate the problem. With strategy you can extend the single dimensionality of single inheritance but you cannot acquire new behavior. Or better it is even more cumbersome if you use it to make it acquire new things. Or different said: If there is something like a design pattern that is used really often it could be a good idea if the language would support this out of the box, right? Somewhere in between is the reason why I was asking :) Norbert

Aug. 23, 2013

Re: [Pharo-users] Trait composition on runtime

by StÃ©phane Ducasse

IDE is support key as Johan mentioned. Then the question is what is the correct granularity that will suit future users of a trait. Stef

Aug. 23, 2013

Re: [Pharo-users] Trait composition on runtime

by StÃ©phane Ducasse

> >> Hi Norbert, >> >> It sounds like you want something like talents Talents http://scg.unibe.ch/research/bifrost/talents. >> However, there is no running version on pharo 3.0 yet. >> >> I am not aware of work on object-specific traits, I could be wrong though. >> > you might be right. The way talents work is basically what I am asking for. I never got into depth with talents and thought it is much more than adjustment of behavior on per object base. I was hoping there are some easy things available to use in order to modify behavior lookup. I should have a look at talents. Thanks for the tip. would strategy not solve your problem? Stef

Aug. 23, 2013

Re: [Pharo-users] Rw engine and Patterns for searching

by Camille Teruel

On 23 aoÃ»t 2013, at 05:16, Gisela Decuzzi wrote: > Hi Camille! > Thanks for the details about using the dot. > I know that for this case is better matching an expression but it sounded strange at the begining the behavior inside the block despite of the ``@ As far as I understand, there is no difference between ` and `` when you try to match a method because there is no such thing as a submethod. No matter where you recurse in a method, you'll never find another method that can potentially match. > I will take a look in the matching. Good luck. Stef suggested to see in visualworks if there is a new version. > Because like that we cannot say that we don't care if we have that piece of code and we should repeat the pattern with an or containing the block and without it. What you can do is still to try matching an expression but with an additional condition. By the way I forgot to mention the `{ :node | "some smalltalk code here" } syntax in my last mail: it permits to match only the nodes that satisfy the "wrapped block". > But I don't understand if the actual behavior is really a bug or it's a feature... Its more a limitation. > > > 2013/8/21 Camille Teruel <camille.teruel(a)gmail.com> > Hello Gisela, > > On 21 aoÃ»t 2013, at 15:43, Gisela Decuzzi wrote: > >> Hello, I'm trying to understand how to define a correct pattern and I'm lost with the cases where I use a method pattern and the desired code is inside a block. >> In the case where we search (methods) with metavariables and the code is inside a block. >> >> An Example: >> >> This pattern >> `a: `aa `b: `bb >> | `@temps | >> ``@.Stats. >> ``@.some size ``@.more. >> ``@.Stats2. > > Putting a dot after the @ means that you want to match statements. > So '``@.some size' cannot match: 'arg1 size'. > >> Does not match with: >> insideABlock: arg1 part2: arg2 >> |temp1 temp3| >> [arg1 size]. >> temp1 := arg2 + 3. >> ^arg2 > > Then even if you remove the extra dots, the rule won't match the method you give. > This is because this method has no statements matching '``@some size' (even if it has a block that has a statement that can). > So here is a rule that can match your method: > `a: `aa `b: `bb > | `@temps | > `@.stms1. > [ `@rcv size ]. > `@.stms2. > > >> After looking while I realize that is not matching with >> part1: arg1 part2: arg2 >> |temp1 temp2 temp3| >> arg1 size. >> temp1 := arg2 + 3. >> ^arg2 > > This one however can be matched by your rule (without the extra dots). > I think that you should try to parse expressions instead of full methods (RBParseTreeSearcher>>#matches:do: instead of RBParseTreeSearcher>>#matchesMethod:do:). > You could just try to match '`@rcv size': it would succeed in both methods. > >> >> Until I understand: >> ``@.some size ``@.more. >> This should mean: anything that sends the message size, doesn't matter if we have something before or after, I think that this expression should match both cases. >> >> But maybe I'm missunderstanding the patterns (again). > > It should work like that (modulo bugs) > ` denotes a metavariable > adding @ means you're looking for a list of elements > ex: `receiver `@msg: `@arg matches every message > adding a . means you're looking for a statement (or a list of statement if you combine it with @) > adding # means you're looking for a literal > adding another ` means that the pattern will be searched recursively in each subexpressions even if the top one already matched > it sometimes leads to infinite loops, but I don't remember exactly when > ex: in 'foo bar bar' : > if you search for '`rcv bar' you'll find one match ('foo bar bar') > if you search for '``rcv bar' you'll find two matches ('foo bar' and 'foo bar bar'). > and I think it's all > >> >> Any help with this will be really welcome! >> >> > >

Aug. 23, 2013

Re: [Pharo-users] Rw engine and Patterns for searching

by Gisela Decuzzi

Hi Camille! Thanks for the details about using the dot. I know that for this case is better matching an expression but it sounded strange at the begining the behavior inside the block despite of the ``@ I will take a look in the matching. Because like that we cannot say that we don't care if we have that piece of code and we should repeat the pattern with an or containing the block and without it. But I don't understand if the actual behavior is really a bug or it's a feature... 2013/8/21 Camille Teruel <camille.teruel(a)gmail.com> > Hello Gisela, > > On 21 aoÃ»t 2013, at 15:43, Gisela Decuzzi wrote: > > Hello, I'm trying to understand how to define a correct pattern and I'm > lost with the cases where I use a method pattern and the desired code is > inside a block. > In the case where we search (methods) with metavariables and the code is > inside a block. > > An Example: > > This pattern > `a: `aa `b: `bb > | `@temps | > ``@.Stats. > ``@.some size ``@.more. > ``@.Stats2. > > > Putting a dot after the @ means that you want to match statements. > So '``@.some size' cannot match: 'arg1 size'. > > Does not match with: > insideABlock: arg1 part2: arg2 > |temp1 temp3| > [arg1 size]. > temp1 := arg2 + 3. > ^arg2 > > > Then even if you remove the extra dots, the rule won't match the method > you give. > This is because this method has no statements matching '``@some size' > (even if it has a block that has a statement that can). > So here is a rule that can match your method: > `a: `aa `b: `bb > | `@temps | > `@.stms1. > [ `@rcv size ]. > `@.stms2. > > > After looking while I realize that is not matching with > part1: arg1 part2: arg2 > |temp1 temp2 temp3| > arg1 size. > temp1 := arg2 + 3. > ^arg2 > > > This one however can be matched by your rule (without the extra dots). > I think that you should try to parse expressions instead of full methods > (RBParseTreeSearcher>>#matches:do: instead > of RBParseTreeSearcher>>#matchesMethod:do:). > You could just try to match '`@rcv size': it would succeed in both methods. > > > Until I understand: > ``@.some size ``@.more. > This should mean: anything that sends the message size, doesn't matter if > we have something before or after, I think that this expression should > match both cases. > > But maybe I'm missunderstanding the patterns (again). > > > It should work like that (modulo bugs) > > - ` denotes a metavariable > - adding @ means you're looking for a list of elements > - ex: `receiver `@msg: `@arg matches every message > - adding a . means you're looking for a statement (or a list of > statement if you combine it with @) > - adding # means you're looking for a literal > - adding another ` means that the pattern will be searched recursively > in each subexpressions even if the top one already matched > > > - it sometimes leads to infinite loops, but I don't remember exactly > when > - ex: in 'foo bar bar' : > - if you search for '`rcv bar' you'll find one match ('foo bar > bar') > - if you search for '``rcv bar' you'll find two matches ('foo > bar' and 'foo bar bar'). > - and I think it's all > > > > Any help with this will be really welcome! > > > >

Aug. 23, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Am 22.08.2013 um 22:03 schrieb Juraj Kubelka <juraj.kubelka(a)gmail.com>: > > El 22-08-2013, a las 14:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> escribiÃ³: > >>>> >>>>> Does pharo support runtime trait composition or does it only work on class definition time. I mean something like >>>>> >>>>> anObject addTrait: MySpecialCapability >>>>> anObject removeTrait: MySpecialCapability >>>> >>>> Nope :) >>>> traits are static :) >>> >>> Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :) >> >> :) >> >> What I think is that traits are cool but not powerful enough but even the ones that we have right now >> makes the system more complex and this is what makes me sad :) I would prefer something more powerful >> and simpler: the graal :) >> >> Stef > > Interesting. Is it only problem of system complexity? I have the impression the problem is that people do not changed his mind in order to think in traits. (or generally speaking in any other system like mixins, aspects, etc.) It looks like objects with single-inheritance are simple and powerful enough. > I think system complexity matters a lot because it is one of the facts why software systems fail. If "people do not change their minds" it is a question about the timeframe you watch people not adjusting. People do not like to change but if things are there they may adjust to it (slowly). Being fast in judging something down is as good as not recognizing that an approach is suboptimal. To be honest while looking at all the people I've met in my career I couldn't find that people have adjusted to OO (,yet). This could indeed be a sign that the whole approach is not applicable. I found traits an interesting approach in the beginning but I don't really like them how they are. I'm not sure if this is dependent on traits or the fact that I have doubts that classes are a good approach. At least I would like to have a looser/lighter approach to compose some behavior at runtime. Just like we do not only have compiled methods but also blocks. To me behavior composition is less about defining types like we do with static traits. It is more about adjusting behavior at runtime depending on the execution context. We have a single inheritance system that is good. And we use a lot of delegations to escape the limits of this approach. Bringing this spirit closer to the language enables IMHO more expressive programs and could enable a lot more things. my 2 cents, Norbert > Or maybe any system like traits have not come with efficient enough IDE? > > Cheers, > Jura

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Am 22.08.2013 um 20:12 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>>> Does pharo support runtime trait composition or does it only work on class definition time. I mean something like >>>> >>>> anObject addTrait: MySpecialCapability >>>> anObject removeTrait: MySpecialCapability >>> >>> Nope :) >>> traits are static :) >> >> Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :) > > :) > > What I think is that traits are cool but not powerful enough but even the ones that we have right now > makes the system more complex and this is what makes me sad :) I would prefer something more powerful > and simpler: the graal :) > Agreed. A simple prove that there is a more powerful approach to this small-shared-state-thingies-we-love exists would be nice :) Norbert

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Am 22.08.2013 um 20:29 schrieb Johan Fabry <jfabry(a)dcc.uchile.cl>: > > Norbert, do you want to be able to programmatically add and remove traits at runtime? I wrote a small utility for that a while ago that still works OK (All tests are still green in 2.0). See http://www.squeaksource.com/TraitsApplication.html > > Hope this helps. > Thanks. My high hopes were to get something to tweak behavior composition on an object base. I did not have a look at TraitsApplication, yet. But it sounds like it operates on behavior. The background of my inquiry is just a thought experiment. Thinking about it I might get away with a hacked version of cloning classes, adjust the trait composition and reassign the class of the objects I need to work on. Norbert > On Aug 22, 2013, at 1:19 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Sad. You know I was not asking about trait but about runtime composable behavior. I'm not sure what you mean with "traits are static". If traits are static in pharo that's fine. If you think traits are static by design then I was looking for something that has a different name :) > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Aug. 22, 2013

Re: [Pharo-users] Trait composition on runtime

by Norbert Hartl

Jorge, Am 22.08.2013 um 15:28 schrieb Jorge Ressia <jorge.ressia(a)gmail.com>: > Hi Norbert, > > It sounds like you want something like talents Talents http://scg.unibe.ch/research/bifrost/talents. > However, there is no running version on pharo 3.0 yet. > > I am not aware of work on object-specific traits, I could be wrong though. > you might be right. The way talents work is basically what I am asking for. I never got into depth with talents and thought it is much more than adjustment of behavior on per object base. I was hoping there are some easy things available to use in order to modify behavior lookup. I should have a look at talents. Thanks for the tip. Norbert > Cheers, > > > On Thu, Aug 22, 2013 at 3:23 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Does pharo support runtime trait composition or does it only work on class definition time. I mean something like > > anObject addTrait: MySpecialCapability > anObject removeTrait: MySpecialCapability > > Norbert > > > > > > -- > Jorge Ressia > www.jorgeressia.com

Aug. 22, 2013