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

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

by Johan Fabry

+1 on this point of view On Feb 1, 2014, at 7:09 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > @ Igor > > I guess that I know pretty well poolDictionaries I do not need an explanation. I even found bugs in the previous lookup and now > we have recompilation bugs when changing pools. > > Now how many times gave one lectures to newcomers? > Why do we have new calling initialize? Because after first lecture we HAD to explain metaclasses. > Do we want to continue to stay a close club of smart asses? > > NOOOOOOOOOOOOOOOOOOOOOOOOO > > NOT ME at least > > > @others > > Now people hear me well: you are ready to hear well. Lower the music > > WE WILL change the class definition in Pharo 4 because we want slots. > So be prepared. > > This is not because you did not read nor type this class definition since years (because you do not even > look at it) that > - it will not change > - students do not get overhelmed with it. > > I DO NOT WANT MY SONS TO PROGRAM IN PYTHON/RUBY/JS BECAUSE THIS IS âEASIERâ. Is it clear? > It is BORING to have to say to kids: > - do not care of classvar > - do not care of pooldictionaries > > COME ON when can we open our eyes? > So yes Iâmad at the lack of vision **you** have. But do not worry I have the vision for Pharo. If you do not like it, I cannot do > much for you. Continue rambling how cool was smalltalk 30 years ago. Not me. > We are INVENTING the future here. > > So please focus your energy on how to make pharo simpler, nicer and sexier. > > Stef > ---> 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 Johan Fabry

On Jan 31, 2014, at 4:50 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >> 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. 1, 2014

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

by Johan Fabry

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

Pharo on Debian 7 > failing

by phil＠highoctane.be

I have been trying to get Pharo running on Debian 7 via the ppa thing. After some twists (getting tools installing), here is what I get: Ign http://ppa.launchpad.net wheezy/main Translation-en_GB Ign http://ppa.launchpad.net wheezy/main Translation-en Get:3 http://http.debian.net wheezy/main Translation-en [3,852 kB] Get:4 http://http.debian.net wheezy-updates/main Translation-en/DiffIndex [505 B] Fetched 3,855 kB in 10s (361 kB/s) W: Failed to fetch http://ppa.launchpad.net/pharo/stable/ubuntu/dists/wheezy/main/source/Sourc… 404 Not Found W: Failed to fetch http://ppa.launchpad.net/pharo/stable/ubuntu/dists/wheezy/main/binary-amd64… 404 Not Found E: Some index files failed to download. They have been ignored, or old ones used instead. So, a 404, which I think is related ot the fact that there is nothing for wheezy in place. As matter of fact, there is nothing. Would someone update those contents? Thanks! Phil

Feb. 1, 2014

Slides from Fosdem: Pharo4: Plans and Dreams

by Marcus Denker

Pharo4: Plans and Dreams http://www.slideshare.net/MarcusDenker/2013-fosdempharo4 http://marcusdenker.de/talks/14Fosdem/2013-FOSDEM-Pharo4.pdf

Feb. 1, 2014

Re: [Pharo-dev] Comparing dates

by Sebastian Sastre

Can somebody please clarify if this is a bug or feature? thanks On Jan 31, 2014, at 9:03 PM, Sebastian Sastre <SEBASTIAN(a)FLOWINGCONCEPT.COM> wrote: > self assert: Date today = Date today. > > today := Date today translateTo: 2 hours. > self assert: today = Date today > > Is this right? > > > >

Feb. 1, 2014

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

by Sebastian Sastre

On Feb 1, 2014, at 8:09 AM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > WE WILL change the class definition in Pharo 4 because we want slots. > So be prepared. If by slots you mean this: http://forum.world.st/Slot-class-builder-Anonymous-class-modification-td472… It sounds good. It seems to make possible to have a cleaner thing AND add conveniences for power users So this early clean up was just anxiety, it shouldnât have happen because is noise. It adds a problem without the benefits. Slots sounds like the real deal

Feb. 1, 2014

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

by Sebastian Sastre

On Feb 1, 2014, at 10:41 AM, Lorenzo Schiavina <lorenzo(a)edor.it> wrote: > Just the same in all the world! What do you mean Lorenzo? care to elaborate so your comment adds something? thanks

Feb. 1, 2014

R: poolDictionaries removal breaks my projects

by Lorenzo Schiavina

Just the same in all the world! Lorenzo Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Sebastian Sastre Inviato: sabato 1 febbraio 2014 13:33 A: Pharo Development List Oggetto: Re: [Pharo-dev] poolDictionaries removal breaks my projects 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

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

by Sebastian Sastre

>> 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