February 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Johan Fabry

On Feb 1, 2014, at 8:59 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >>> If your students have problems to grasp the concept of pool dictionaries then how do they deal with mathematics and computer science? >> >> Given enough time, no problem. But time in class and outside is limited enough as it is. > > No johan even if I multiply by two the amount of time you have you will not spend time on such uninteresting concept when > we have so much more beautiful concepts to show. There is a difference between being able to do it, and me wanting to to it :-). I don't want to because of the same reasons as you, apparently. I am just defending my students here :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

Feb. 2, 2014

Re: [Pharo-dev] Can someone help me with this issue 12469 (Sometimes an empty protocol is created)

by Pharo4Stef

sorry for this situation. It is not the one we dream about believe me. Stef On 01 Feb 2014, at 18:29, Nicolai Hess <nicolaihess(a)web.de> wrote: > I tried a dozen times to create a slice for the fix. > Every time the slice marks the all classes and methods as changed, > even so, I only changed some methods. > > Now I have finally uploaded a slice with only my changes but.. > The Validator chooses an older slice for validation ? > (https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/9284//artifact/vali…) > > I don't know anymore, what I can do, I despair. > > > Nicolai > >

Feb. 2, 2014

poolDictionaries removal breaks my projects

by Pharo4Stef

yes johan you are right again :) Stef >> OK, back to topic and to summarize: we now all fully understood that the original message >> including pools is still there, will not break code loading or other things and that the >> change is on the Nautilus level. > > Yes, thanks for understanding and summarizing well. > >> But still the simple question left to be anwered here: what will this change of reducing the >> class template in the default browser give us? What problem did it really solve? >> >> The answer given so far is that it may be problematic when teaching because you want to >> introduce to language features step by step. But you said yourself in your own post >> that >> >> <quote> >> It is BORING to have to say to kids: >> - do not care of classvar >> - do not care of pooldictionaries >> </quote> >> >> So my question: if you are bored of the "complexity" of BOTH (!) >> - why do we hide pools now >> - and leave class variables still left in the template? >> >> I really do not understand because with the change it now looks in >> Pharo3.0 Latest update: #30732 like this: >> >> Object subclass: #Foo >> instanceVariableNames: '' >> classVariableNames: '' >> category: 'Bar' >> >> So why do we keep class vars then? According to your mail we would have to remove them too. > > From my point of view this is a different design decision to take since it is a different feature of the language. So it is not included in the change that I proposed. And BTW I leave it to somebody else to make the call and propose a change to Pharo that addresses this (or not, as may be the case). > >> Additionally this change violates the intention of a template (which one usually just has to fill out) >> and one now has to remember the original full keyword and have to type it in again - which is IMHO >> really awkward and stupid. >> >> So with all respect: I still can not see the introduction of the reduced template as a step forward >> or an improvement. > > For me, this reduces to the case of Traits. A low usage (arguably), so uses: is not present in the template. We do the same for pooldictionaries. If you are against this, and say that you should just fill in the template, then logically you should be against how Traits are handled. Following that logic, you are advocating for: > > Object subclass: #NameOfSubclass > uses: '' > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: '' > > Am I correct? > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Feb. 2, 2014

poolDictionaries removal breaks my projects

by Pharo4Stef

>> >> There are some kinds of students who are going to find Smalltalk difficult, yes. I do not see how removing pooldictionaries from the class creation template will affect them. If they ask about them, you can say that they are there and point them to the new class creation message. And take advantage of that to say that class creation is just a message send while you are at it :-) > > If your students have problems to grasp the concept of pool dictionaries then how do they deal with mathematics and computer science? This is the proof that you never taught. I never got the time to arrive to pool. Why would I teach them something that I used two times over the last 15 years of programming (ok I just wrote moose and some parts of Pharo :). Why should I spend time on a detail when I can teach them real OO design? Do you think that I attract people to Smalltalk teaching them about Pool? or because I ask them why the way boolean is implemented is so mind-blowing? I let you guess. Now during my last lectures (4.5 h in total this year). One guy leo came after the lecture and told that he loves the way boolean are implemented and that he wants to an internship with us. Is it enough or I should continue? >>>> âoldtimersâ need freedom. This is one of the reasons I really enjoy dynamic typing and Smalltalk. I donât like to obey to artificial rules that only >>>> put permanent burden to me in order to protect me from something I might do wrong sometimes. >> >> You still have the freedom to use pool dictionaries. They are still there. > They are hidden for the sake of simplicity for some students. > I want my pool dictionaries back :-D Donât use them you do not need them. Why you cannot express the same with a class and a classvar + messages? >>>> >>> >>> If you donât see features you donât know what the machine can do for you. >>> >>> Obscuring things is sometimes a good design strategy, but here there is a well known artefact breaking tradition here, that isnât something light. And the proposed alternative design is far to be better (read: have been proven itself worth of its added burden of breaking that tradition) >> >> So if we cannot break tradition then Traits should never have been introduced? > Traits are a different kind of thing. They didnât cripple existing elements in Pharo. really? did you see the real class template with traits? It should be like that if we follow your reasoning Object subclass: #NameOfSubclass uses: T1 (#bar -> #zork) + T2 - {#foo} instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'CollectionsTests-Strings' CollectionRootTest subclass: #StringTest uses: TIncludesTest + TCloneTest + TCopyTest + TSetArithmetic + TIterateSequencedReadableTest + TPrintOnSequencedTest + TAsStringCommaAndDelimiterSequenceableTest + TIndexAccess + TSequencedElementAccessTest + TSubCollectionAccess + TPutBasicTest + TCopySequenceableSameContents + TCopyPartOfSequenceable + TCopyPartOfSequenceableForMultipliness + TCopySequenceableWithOrWithoutSpecificElements + TCopySequenceableWithReplacement + TReplacementSequencedTest + (TConvertTest - {#testAsByteArray}) + TConvertAsSortedTest + TBeginsEndsWith + (TIndexAccessForMultipliness - {#testIdentityIndexOfIAbsentDuplicate. #testIdentityIndexOfDuplicate. #collectionWithNonIdentitySameAtEndAndBegining}) + TSequencedConcatenationTest + TPutTest + TConvertAsSetForMultiplinessTest + TSortTest + TSequencedStructuralEqualityTest + TOccurrencesForMultiplinessTest + TCreationWithTest instanceVariableNames: 'string emptyString elementInNonEmpty notIn nonEmpty1element withoutEqualElements collectionNotIncluded indexInNonEmptyArray sameAtEndAndBegining nonEmpty5ElementsSorted unsortedCollection subcollection3ElementsSorted arrayWithCharacters' classVariableNames: '' poolDictionaries: '' category: 'CollectionsTests-Strings' > The only problem was the lack of tool support when they were introduced. You are comparing apples and oranges. > >> > For generations of Smalltalk newbies it was possible to either grasp the concept or ignore it. How do you measure that we did not fail? > Why do you need to change this without a real solution for those who want to use them? > In my eyes itâs an absolute minority of Pharo users who arenât able to understand the concept. Again let me repeat. This is not a question of not being able to understand or not. This is an accessibility point. Why do we overhelm people with unnecessary information. Now think about it for real (read what I wrote) because I will stop reading this thread. >>> Itâs a half-ass non-solution >>> >>> Do you really love cleaning that up? >> >> >> This half-assed non-solution is the same solution as for Traits, essentially. Do you have the same issue with Traits? >> > Again you are comparing apples and oranges. Traits didnât take away anything but brought something new. No :) This is why I do not like traits. > You took away something. > BTW how do your students cope with Traits? They must be completely overwhelmed. They do not see them. because empty traits are not in the class template nor in the definition of classes that do not use them. Can you reread this sentence please? > And how do you teach the class hierarchy and meta classes? much simpler. > > > >>> The second part of your homework on this design decision was completely ignored so expecting it to be loved (popular) is unrealistic >>> >>> And by not doing that you just added a problem where there was none >>> >>> Not willing to do that second part? >>> >>> Then donât fix what isnât broken. >> >> Please see previous mail. > > I am a close lurker of the mailing lists and I completely missed it. > > Regards, > Andreas

Feb. 2, 2014

Paths to remove leading char

by Pharo4Stef

Hi guys I started to understand the leadingChar and I would like to get ideas about a possible path to remove the leading char. If you have an idea of the possible steps that we perform to make progress in Pharo 40 Iâm all ears open. Stef

Feb. 2, 2014

Fwd: poolDictionaries removal breaks my projects

by Pharo4Stef

From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> Subject: Re: [Pharo-dev] poolDictionaries removal breaks my projects Date: 2 Feb 2014 00:30:04 GMT+1 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Johan YOU ARE RIGHT, RIGHT, RIGHT, RIGHT. I spent a significant amount of time teaching Smalltalk to know that you are right. And this change will be in the system :) Just people that know something totally ignore what is it to learn something. Imagine people are scared and close the debuggers. Oscar wrote patterns and I always say the debugger is your best friend so do not close it. Stef > >>> I donât see how this change make Smalltalk (the language) simpler. For me this change looks more like an obfuscation than a simplification. >> >> How many lectures did you give? It is annoying to have to explain something that usually people do not need to know. > > To complement this: in my own experience as a full-time prof, whenever you are teaching and at a given point you need to say: 'I cannot explain this yet' or resort to handwaving there is something wrong. Do I need to explain pooldictionaries to be able to talk about class creation? No, I should not need to do that. > > I get this feeling with Java all the time. First hello world example in Java is always a mess. public static void main(String[] args) OMG. Start to explain all that just to do a println? Were is the simplicity there? I don't want to have this kind of feeling when I explain Smalltalk. > >>> How should newcomers know how to enter pool dictionaries? I rarely use pool dictionaries and if I will need it I surely have forgotten about >>> this change and expect irritation and frustration. >> >> Newcomers do not use pooldictionaries. In 10 years smalltalking I used them twice. > > I agree with Stef that pooldictionaries are advanced features. I have been Smalltalking since 1998 and I have never used them. > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Feb. 2, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Pharo4Stef

>> >> If your students have problems to grasp the concept of pool dictionaries then how do they deal with mathematics and computer science? > > Given enough time, no problem. But time in class and outside is limited enough as it is. No johan even if I multiply by two the amount of time you have you will not spend time on such uninteresting concept when we have so much more beautiful concepts to show. > >>> You still have the freedom to use pool dictionaries. They are still there. >> They are hidden for the sake of simplicity for some students. >> I want my pool dictionaries back :-D > > For simplicity of everybody that is learning the language, and everybody that writes a class without pool dicts. Note that they are still there! Just write pooldictionaries: in the next-to-last line and done. > >>>> Obscuring things is sometimes a good design strategy, but here there is a well known artefact breaking tradition here, that isnât something light. And the proposed alternative design is far to be better (read: have been proven itself worth of its added burden of breaking that tradition) >>> >>> So if we cannot break tradition then Traits should never have been introduced? >> Traits are a different kind of thing. They didnât cripple existing elements in Pharo. The only problem was the lack of tool support when they were introduced. You are comparing apples and oranges. > > I repeat. Nothing is broken. Pool dictionaries are still there. So the comparison stands. > >>>> Yeah, youâre not the only one with that perception. >>>> >>>> This move sucks. It allegedly solved a problem that allegedly happens to some by creating a problem for almost everybody. >>> >>> I have an issue with your "problem for almost everybody" statement. Pooldictionaries are rarely used. Look at the classes in the image. Can you argument why this then is a problem for almost everybody ? I do not see how you get to this conclusion. >> For generations of Smalltalk newbies it was possible to either grasp the concept or ignore it. >> Why do you need to change this without a real solution for those who want to use them? >> In my eyes itâs an absolute minority of Pharo users who arenât able to understand the concept. > > The problem is not understanding the pooldictionaries. The problem is the people that use them. Are you saying that it is a problem for everybody that the template is now without a line that they do NOT use? In that case we should not touch anything and not make any changes. :) >>> This half-assed non-solution is the same solution as for Traits, essentially. Do you have the same issue with Traits? >>> >> Again you are comparing apples and oranges. Traits didnât take away anything but brought something new. >> You took away something. > > I repeat. Pool dictionaries are still there. I did not take away anything. Essentially I am doing the same as with traits: if you use them you see them, if not, not. The comparison stands. Some people do not understand that in EBNF you can have optional parts :) > >> BTW how do your students cope with Traits? They must be completely overwhelmed. >> And how do you teach the class hierarchy and meta classes? > > Yes, I do teach them because I have the *time* to do it. I have the time to do it because I can focus on the essential and not lose it explaining obscure features. YES like a good teacher always does. > >>> Please see previous mail. >> >> I am a close lurker of the mailing lists and I completely missed it. > > > Sent today at 10:37 AM chilean time, a few minutes before I sent the mail you are replying to. Same subject as this mail. For completeness, here is the content: > >> For what it's worth: this was asked on the users list (some months ago). There were about 5 replies and they were positive. I do not recall having any negative replies. >> >> I think that asking much more than that is hard, given the nature of mailing lists and the comity being busy with many other things. >> >> Also, having learned about user studies and performed a few (for this "science" thing I'm supposed to be doing), I can tell you that getting a really representative group of users together is nearly impossible in the scenario we are in. So anything you can get out of an inquiry will just be 'some people say: OK'. Nothing is guaranteed about other people. Which is just what is happening here ! ;-) >> >> On Jan 31, 2014, at 6:43 PM, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: >> >>> Lets says it convinces youâ¦ >>> >>> Time to be skeptic. Test. >>> >>> Test with someone else. Tests it with 5 guys and ask how they feel about it. >>> >>> Hear. > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

Feb. 1, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Pharo4Stef

> Hi Stef, > >> Now people hear me well: you are ready to hear well. Lower the music > > Beside the fact that I like listening to loud music I really lowered it ;) > But even with silence in the room your response told me nothing new regarding > the topic discussed. Then read it again :) Because it is really serious and I will just repeat the same. Pharo should be welcoming. I hate the kind of teaching: âyou had a lot of barriers to get there and you succeeded, of course 95% of the classrooms died in the process and prefered JS" > It is not a discussion about "who has the vision" or "who want to get stuck" > I think we all share the SAME VISION to move forward with a fresh dynamic > programming environment and are not afraid if we move away from our original roots. > Otherwise we would'nt be on this list or do even radical changes. I do not know. So far you are the first ones that ask interesting questions :). To me the other complaints were more like arguments against changes. > But still the simple question left to be anwered here: what will this change of reducing the > class template in the default browser give us? What problem did it really solve? shorter, nicer, simpler class definition :) > The answer given so far is that it may be problematic when teaching because you want to > introduce to language features step by step. But you said yourself in your own post > that > > <quote> > It is BORING to have to say to kids: > - do not care of classvar > - do not care of pooldictionaries > </quote> > > So my question: if you are bored of the "complexity" of BOTH (!) > - why do we hide pools now > - and leave class variables still left in the template? Because classVar and more central I would remove them too and I REALLY hope we will. I hate to see all these empty strings all the time. In the template why not but why in the class definition? > I really do not understand because with the change it now looks in > Pharo3.0 Latest update: #30732 like this: > > Object subclass: #Foo > instanceVariableNames: '' > classVariableNames: '' > category: âBar' Because we did not remove them yet but I would love that too. And because classVar are more central that Pool. > So why do we keep class vars then? According to your mail we would have to remove them too. Yes and instance variables too :) Donât faint but why do we need an empty list of instance variables for classes that do not define instance variables? Seriously: lack of good default value? lack of understanding what is optional? To me a class is a name superclass package then optional and in any order instance variables, class var and to make happy everybody pool > Additionally this change violates the intention of a template (which one usually just has to fill out) > and one now has to remember the original full keyword and have to type it in again - which is IMHO > really awkward and stupid. Yes I was talking about the actual class definition not the template > > So with all respect: I still can not see the introduction of the reduced template as a step forward > or an improvement. > > Music is still lowered and ears are all open... > > Thx > T. >

Feb. 1, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Pharo4Stef

> > So if we cannot break tradition then Traits should never have been introduced? indeed :) without this breaks Java8 would not have them. And why on earth new invokes initialize this was not like that when I learned Smalltalk! Sorry I could not resist. Stef

Feb. 1, 2014

Re: [Pharo-dev] poolDictionaries removal breaks my projects

by Pharo4Stef

Sorry sebastian but you are wrong :) and start to be ready for changes in the future too or stay with Pharo 2.0 Look at the Pharo Motto. Stef On 01 Feb 2014, at 13:32, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >>> How many lectures did you give? It is annoying to have to explain something that usually people do not need to know. >> I donât give any lectures to students but I often try to âteachâ Smalltalk to some of my colleagues and friends. And with that I have hard times. >> Typically âexperiencedâ software developers think about themselves as being experts in object orientation and programming languages, >> even if they have only experiences with C, C# and C++. âTeachingâ them about Smalltalkâs idea of object orientation is VERY hard, almost >> impossible because they already know everything (read: they are ignorant) and lazy. I guess there are some similarities to students. > > +1 on this > > >>> >>> Newcomers do not use pooldictionaries. In 10 years smalltalking I used them twice. >> Newcomers donât use a lot of things but that should not be a reason to hide them. In my experience newcomers need guidance and rules but >> âoldtimersâ need freedom. This is one of the reasons I really enjoy dynamic typing and Smalltalk. I donât like to obey to artificial rules that only >> put permanent burden to me in order to protect me from something I might do wrong sometimes. >> >> At the moment I am considering pool dictionaries for a solution of a problem at hand: I need to collect some information (warnings, errors, and reports) over lots of related and unrelated classes. For the moment I have parameters, but that is getting inconvenient with a growing number of things to collectâ¦ >> So, if you need something it should be there and not necessarily obscured and hidden! >> > > If you donât see features you donât know what the machine can do for you. > > Obscuring things is sometimes a good design strategy, but here there is a well known artefact breaking tradition here, that isnât something light. And the proposed alternative design is far to be better (read: have been proven itself worth of its added burden of breaking that tradition) > > Students shouldnât be underestimated they can handle ignoring what they donât need, no problem > >>> >>> We just need a full class template menu item. >> Yes, but itâs not there yet but this change already took away some power without giving me back something in exchange! >> I am able to ignore some parts of class creation message easily (I also donât use class variables that often) and I donât see why students >> shouldnât be able, too. Quite contrary I think if you hide these things from students they wonât see it, wonât get curious and in the end will only >> learn the boring parts of Smalltalkâ¦ >> > Yeah, youâre not the only one with that perception. > > This move sucks. It allegedly solved a problem that allegedly happens to some by creating a problem for almost everybody. > > Itâs a half-ass non-solution > > Do you really love cleaning that up? > > Go ahead and do it after you prove to us (non-newcomers, so non-early adopters but conservatives users) that your alternative not only is clean but rocks (more convenient is some other way). > > The second part of your homework on this design decision was completely ignored so expecting it to be loved (popular) is unrealistic > > And by not doing that you just added a problem where there was none > > Not willing to do that second part? > > Then donât fix what isnât broken. >

Feb. 1, 2014