Re: [Pharo-dev] poolDictionaries removal breaks my projects
The behavior that Stef explains is indeed what was intended: when they are used show them, when not, not. This is just like Traits. The implementation was broken in this respect though. Sorry for that. I have submitted a fix. https://pharo.fogbugz.com/f/cases/12752 Note that the original way in which classes are created was never adapted, only the way the classes are shown in Nautilus is different than before. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Please make it a setting - so one can see the creation message with poolDictionaries in Nautilus as before in the browser and is able to fill out the template. When using NB one requires them. Thx T.
I don't see why there needs to be a configuration for that. You can still add them, just put pooldictionaries: 'foo bar' on the next-to-last line as it was before, et voilá ⦠you have them in your class. This is the same behavior as traits and the uses: message. There is not configuration option present for that, AFAIK. On Jan 31, 2014, at 4:42 AM, "Torsten Bergmann" <astares@gmx.de> wrote:
Please make it a setting - so one can see the creation message with poolDictionaries in Nautilus as before in the browser and is able to fill out the template.
When using NB one requires them.
Thx T.
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
just to be clear: Iâm not agains this change, I think is a good one. I just was (and I still am) pissed with the fact that we do not fully understand the signification of âfrozenâ version, and sometimes I feel like nobody notices the HUGE effort that means to close a version in a reliable and stable way :) Said so⦠I still does not understand why this particular change couldnât wait for pharo 4. But well⦠now is there, so it needs to work fine. Esteban On 31 Jan 2014, at 12:55, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
I don't see why there needs to be a configuration for that. You can still add them, just put pooldictionaries: 'foo bar' on the next-to-last line as it was before, et voilá ⦠you have them in your class.
This is the same behavior as traits and the uses: message. There is not configuration option present for that, AFAIK.
On Jan 31, 2014, at 4:42 AM, "Torsten Bergmann" <astares@gmx.de> wrote:
Please make it a setting - so one can see the creation message with poolDictionaries in Nautilus as before in the browser and is able to fill out the template.
When using NB one requires them.
Thx T.
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Le 31/01/2014 13:21, Esteban Lorenzano a écrit :
Said so⦠I still does not understand why this particular change couldnât wait for pharo 4. But well⦠now is there, so it needs to work fine.
As long as you don't learn to reject, you will face this situation over and over. Believe me. Hilaire -- Dr. Geo http://drgeo.eu
Hi Johan, Still I really do not understand what particular problem that is solved by changing the template from MySuperclass subclass: #Foo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Bar-Core' to MySuperclass subclass: #Foo instanceVariableNames: '' classVariableNames: '' category: 'Bar-Core' other than some of your student had problem not yet knowning what pool dictionaries are and you want to hide pools therefore. A weak argument since some students may not yet know about class variables - so why not hiding them in the first place too? Another teacher may argue that his students got problems because the template was changed and nearly all ST, Seaside and Pharo books used for teaching include the extended variant of the message. IMHO a class template is (as the name says) a "template" and a template should be something one just has to fill out. The idea of a template is to avoid too much typing afterwards. So the idea is one just should fill out the template without much hazzle. If I require an ivar, a class variable, a pool or a category I just put it in. By now reducing the template people who require pools have to do more typing and they have to remember the order of words in the keyword message... I stand at my point I think there is not much real value in this change of the default template, but are fine if community agrees on the reduced version. Thanks T.
Hi Torsten, I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it. When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision. But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work. The fix I proposed was integrated today, so everything should work now. If there still is a problem I will provide a fix as soon as I get notified of the issue (as I did yesterday). My apologies to all for the mess, I promise I won't cause such a mess again in the future. On Jan 31, 2014, at 9:54 AM, "Torsten Bergmann" <astares@gmx.de> wrote:
Hi Johan,
Still I really do not understand what particular problem that is solved by changing the template from
MySuperclass subclass: #Foo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Bar-Core'
to
MySuperclass subclass: #Foo instanceVariableNames: '' classVariableNames: '' category: 'Bar-Core'
other than some of your student had problem not yet knowning what pool dictionaries are and you want to hide pools therefore. A weak argument since some students may not yet know about class variables - so why not hiding them in the first place too?
Another teacher may argue that his students got problems because the template was changed and nearly all ST, Seaside and Pharo books used for teaching include the extended variant of the message.
IMHO a class template is (as the name says) a "template" and a template should be something one just has to fill out. The idea of a template is to avoid too much typing afterwards. So the idea is one just should fill out the template without much hazzle. If I require an ivar, a class variable, a pool or a category I just put it in.
By now reducing the template people who require pools have to do more typing and they have to remember the order of words in the keyword message...
I stand at my point I think there is not much real value in this change of the default template, but are fine if community agrees on the reduced version.
Thanks T.
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Am 31.01.2014 um 14:40 schrieb Johan Fabry <jfabry@dcc.uchile.cl>:
Hi Torsten,
I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it.
I donât see how this change make Smalltalk (the language) simpler. For me this change looks more like an obfuscation than a simplification.
When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision.
But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work.
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. So, a -1 for this change from my side. Regards Andreas
On Jan 31, 2014, at 2:03 PM, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:
Am 31.01.2014 um 14:40 schrieb Johan Fabry <jfabry@dcc.uchile.cl>:
Hi Torsten,
I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it.
I donât see how this change make Smalltalk (the language) simpler. For me this change looks more like an obfuscation than a simplification.
It's simpler because very infrequently used things are not immediately exposed. Again this is a matter of where the design tradeoff is made. If it would be used a lot it would indeed be obfuscation.
When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision.
But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work.
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.
I understand that when you want to use it and it is not there there is a cost. Especially if you have forgotten how the message goes. BUT it is a message send, just like any other in Smalltalk. Open a method finder and look for methods with pooldictionaries in there. In 15 seconds you find it. I think that is an acceptable period of time of irritation and frustration. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Hi Torsten,
I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it.
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.
When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision.
But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work.
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.
So, a -1 for this change from my side.
We just need a full class template menu item.
Let's make Nautilus menu longer with a full class template ! -1, Honestly Shortening the default class description is also painfull when you port code, because it makes the class appear different (description with and without pool dictionaries) in the change sorter. I wrote a pac change reader to port SmaCC from Dolphin to Pharo, and, really, this kind of change makes that unusable. In short, make that change correctly: at the Nautilus level. It's a GUI issue, not a language issue. Just go your average GUI approach : a wizard for creating classes, with at least ten "Next" to go through for each class creation ;) As an aside: I suspect there are others low-levels Smalltalk langage features that we feel engaged to change or hack them because they appear straight through the GUI, instead of being mapped to whatever flavor of the day in the GUI. A list of recent changes which do belong to that: The all protocol. A special AST node type for #subclass:instanceVariables:... Some of RPackage features and requests (which, I think, have the nice side effect of making RPackage harder to implement) Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Pharo4Stef [pharo4Stef@free.fr] Date d'envoi : vendredi 31 janvier 2014 20:50 Ã : Pharo Development List Objet : Re: [Pharo-dev] poolDictionaries removal breaks my projects
Hi Torsten,
I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it.
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.
When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision.
But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work.
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.
So, a -1 for this change from my side.
We just need a full class template menu item.
Please note that the change IS at the Nautilus level. The default class description is the same as before! Your class porting example is unharmed by this change. On Feb 1, 2014, at 7:16 AM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Shortening the default class description is also painfull when you port code, because it makes the class appear different (description with and without pool dictionaries) in the change sorter. I wrote a pac change reader to port SmaCC from Dolphin to Pharo, and, really, this kind of change makes that unusable.
In short, make that change correctly: at the Nautilus level. It's a GUI issue, not a language issue.
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Johan, It wasn't when I ported. Now, it is. Thanks! Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Johan Fabry [jfabry@dcc.uchile.cl] Date d'envoi : samedi 1 février 2014 14:50 à : Pharo Development List Objet : Re: [Pharo-dev] poolDictionaries removal breaks my projects Please note that the change IS at the Nautilus level. The default class description is the same as before! Your class porting example is unharmed by this change. On Feb 1, 2014, at 7:16 AM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Shortening the default class description is also painfull when you port code, because it makes the class appear different (description with and without pool dictionaries) in the change sorter. I wrote a pac change reader to port SmaCC from Dolphin to Pharo, and, really, this kind of change makes that unusable.
In short, make that change correctly: at the Nautilus level. It's a GUI issue, not a language issue.
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Am 31.01.2014 um 20:50 schrieb Pharo4Stef <pharo4Stef@free.fr>:
Hi Torsten,
I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it.
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.
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. So, no I donât teach but have my own problems ;-)
When I say "very infrequently", this is of course a fuzzy metric, I know. And I understand that you do not agree with this design decision.
But on the other hand, I don't think that it is too hard to remember where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work.
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.
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!
So, a -1 for this change from my side.
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â¦
Regards, Andreas
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.
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.
On Feb 1, 2014, at 9:32 AM, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
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
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 :-)
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.
You still have the freedom to use pool dictionaries. They are still there.
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)
So if we cannot break tradition then Traits should never have been introduced?
Students shouldnât be underestimated they can handle ignoring what they donât need, no problem
If I would have infinite time, and they as well, sure! Be we don't and we need to focus.
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.
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.
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?
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. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Am 01.02.2014 um 15:00 schrieb Johan Fabry <jfabry@dcc.uchile.cl>:
On Feb 1, 2014, at 9:32 AM, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
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
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?
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.
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
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)
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.
Students shouldnât be underestimated they can handle ignoring what they donât need, no problem
If I would have infinite time, and they as well, sure! Be we don't and we need to focus.
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.
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.
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. You took away something. BTW how do your students cope with Traits? They must be completely overwhelmed. And how do you teach the class hierarchy and meta classes?
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
On Feb 1, 2014, at 12:55 PM, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:
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?
Given enough time, no problem. But time in class and outside is limited enough as it is.
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.
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.
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@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
Just to clarify... 5 emails saying âitâs okayâ plus no active complains is a whole different thing than making usability tests with 5 users. I wish so much I could say that Nautilus rocks, seriously Itâs a pity because the community is putting so much effort on it On Feb 1, 2014, at 2:41 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
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@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.
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@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
On Feb 1, 2014, at 8:59 PM, Pharo4Stef <pharo4Stef@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
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
On Feb 1, 2014, at 9:33 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
So if we cannot break tradition then Traits should never have been introduced?
We can. Innovation has a lot to do with that. But you have ways to introduce your innovation that will make all the difference. iPhone broke all the tradition about making mobile phones in the most epic way Again, my problem is not with innovation but with delivering poorly
On Sat, Feb 1, 2014 at 6:00 AM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
On Feb 1, 2014, at 9:32 AM, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
<snip lots of stuff>
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?
personally, yes. When I first tried figuring out how to do Traits, I remember taking a long time tracking down how to add them to a class. Trying to figure out hot to remove them was even harder. And neither of these were helped by auto-hiding of the creation method in the browsers. Or course, now that I've paid that price, I just find one of my classes with Traits in it to refresh my memory of how to use them when I need it next time (since, invariably, it will be many months between uses - if not longer).
-cbc <snip more>
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@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.
Andreas did you realise that pools are just static cached version of (simple value) returning messages?
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. So, no I donât teach but have my own problems ;-)
So when you learn a new language like python do you get all the syntax to create a class as a template? Or just the non optional parts? To me smalltalk class definition forgot the be designed, else variables would have been first class objects like in CLOS MOP
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.
and? you still can use Pool even if I do not really understand why we need them since we have classes and messages. Because Pool are just a static version of that. Did I miss something obvious? Pool may have they place in 1980 to optimize for speed but I would be curious to see if a modern languages using a decent JIT would keep them. Especially since class names should be dynamically looked up.
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 are mixing things. So I will not comment on it.
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.
Then create a class MyRessources and define class methods and you are done. No need to use SharedPool + initialize + poolDictionaryâ¦.
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!
Come on, do you know in EBNF the * notation zero or more or optional?. You do not write your method using all the constructs of your language, donât you? so this is the same for class definition.
So, a -1 for this change from my side.
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!
since you are an experienced programmer this is simple. Look for trait template and send a fix to get an extra menu. I will go to sleep now but I guess that I can do that in 10 min and we are talking about making our system more accesssible to people.
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.
When is the last time you learn a new language for real? I started Python recently because I need some fresh air :) and I could define a class in 3 4 lines within 5 min. Without needing class var, static, delegator... (and if you know python you know that it can be UGLY and COMPLEX) I found blogs of people explaining wrongs some advanced features still many people are able to define a class within the 10 min they started to learn python.
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â¦
You are wrong and you can trust me on that. We want to make sure that people can build fast great stuff and feel good and powerful and not good because they succeeded to jump over the barriers in the middle of the way. Pharo is not an obstacle run, it should be smooth and great. Pharo is not for pedandic programmers or smalltalk bigots, it is for making people been able to build things nicely. Simplicity, simplicity, this is why one challenge for Slot is to enable super users without breaking simplicity. Stef
On Sat, Feb 1, 2014 at 3:25 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
Andreas
did you realise that pools are just static cached version of (simple value) returning messages?
But they are not. They are combinations of a getter and a setter; pools are pools of *variables*, not *constants*. So one variable is replaced by one variable and two methods, in turn adding two symbols. Personally I want to continue to be able to write opcode caseOf: { "Noops & Pseudo Ops" [Label] -> [maxSize := 0]. [AlignmentNops] -> [maxSize := (operands at: 0) - 1]. [Fill16] -> [maxSize := 2]. [Fill32] -> [maxSize := 4]. [FillFromWord] -> [maxSize := 4]. [Nop] -> [maxSize := 1]. ... not opcode caseOf: { "Noops & Pseudo Ops" [CogRTLOpcodes label] -> [maxSize := 0]. [CogRTLOpcodes alignmentNops] -> [maxSize := (operands at: 0) - 1]. [CogRTLOpcodes fill16] -> [maxSize := 2]. [CogRTLOpcodes fill32] -> [maxSize := 4]. [CogRTLOpcodes fillFromWord] -> [maxSize := 4]. [CogRTLOpcodes nop] -> [maxSize := 1]. ... And I don't want to have to define the accessors. It's bloat. It's less readable. Theres still a pool involved (CogRTLOpcodes's classPool); it is just being made harder to get hold of. Pools are really useful. Just because someone's only worked on projects where the need didn't present itself doesn't mean they're not really useful when they can be used. One could say the same about contexts. Should we get rid of them because most people hardly ever use them?
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. So, no I don't teach but have my own problems ;-)
So when you learn a new language like python do you get all the syntax to create a class as a template? Or just the non optional parts? To me smalltalk class definition forgot the be designed, else variables would have been first class objects like in CLOS MOP
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.
and? you still can use Pool even if I do not really understand why we need them since we have classes and messages. Because Pool are just a static version of that. Did I miss something obvious? Pool may have they place in 1980 to optimize for speed but I would be curious to see if a modern languages using a decent JIT would keep them. Especially since class names should be dynamically looked up.
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 are mixing things. So I will not comment on it.
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.
Then create a class MyRessources and define class methods and you are done. No need to use SharedPool + initialize + poolDictionary....
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!
Come on, do you know in EBNF the * notation zero or more or optional?. You do not write your method using all the constructs of your language, don't you? so this is the same for class definition.
So, a -1 for this change from my side.
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!
since you are an experienced programmer this is simple. Look for trait template and send a fix to get an extra menu. I will go to sleep now but I guess that I can do that in 10 min and we are talking about making our system more accesssible to people.
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.
When is the last time you learn a new language for real? I started Python recently because I need some fresh air :) and I could define a class in 3 4 lines within 5 min. Without needing class var, static, delegator... (and if you know python you know that it can be UGLY and COMPLEX) I found blogs of people explaining wrongs some advanced features still many people are able to define a class within the 10 min they started to learn python.
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...
You are wrong and you can trust me on that. We want to make sure that people can build fast great stuff and feel good and powerful and not good because they succeeded to jump over the barriers in the middle of the way. Pharo is not an obstacle run, it should be smooth and great.
Pharo is not for pedandic programmers or smalltalk bigots, it is for making people been able to build things nicely. Simplicity, simplicity, this is why one challenge for Slot is to enable super users without breaking simplicity.
Stef
-- best, Eliot
On Jan 31, 2014, at 4:50 PM, Pharo4Stef <pharo4Stef@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
On 31 January 2014 18:03, Andreas Wacknitz <a.wacknitz@gmx.de> wrote:
Am 31.01.2014 um 14:40 schrieb Johan Fabry <jfabry@dcc.uchile.cl>:
Hi Torsten,
I think it is a design decision / tradeoff, and therefore there is no fundamentally "right way" to do it. For me, it is the same case as the uses: message for Traits. It's not in the template by default because it is used very infrequently. So for language simplicity it should not be there. For me, simplicity is one of the core points of Smalltalk so this is why I feel strongly about it.
I donât see how this change make Smalltalk (the language) simpler. For me this change looks more like an obfuscation than a simplification.
+1
When I say "very infrequently", this is of course a fuzzy metric, I
know. And I understand that you do not agree with this design decision.
But on the other hand, I don't think that it is too hard to remember
where to add the pooldictionaries: line if you need it, and the old message with this line still works, so all old examples still work.
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.
So, a -1 for this change from my side.
+1
Regards Andreas
-- Best regards, Igor Stasenko.
Guys, can you explain me, why you hating pools so much? Because you cannot find good use of them, or because you don't know how to properly use them? Or because you don't understand what is it? Pool dictionary is just a namespace, which you can share among different parts of your code (on a per-class basis). And one of most used form of it is a global one, where all public classes are. The only difference is that access to global pool is implicit (you don't have to mention it in class definition), but it has same nature as shared pool. As long as you need to give names to things you using, you gonna need namespaces/pools. -- Best regards, Igor Stasenko.
@ 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
Guys, can you explain me, why you hating pools so much? Because you cannot find good use of them, or because you don't know how to properly use them? Or because you don't understand what is it?
Pool dictionary is just a namespace, which you can share among different parts of your code (on a per-class basis). And one of most used form of it is a global one, where all public classes are. The only difference is that access to global pool is implicit (you don't have to mention it in class definition), but it has same nature as shared pool.
As long as you need to give names to things you using, you gonna need namespaces/pools.
-- Best regards, Igor Stasenko.
On Feb 1, 2014, at 8:09 AM, Pharo4Stef <pharo4Stef@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-td4724... 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
+1 on this point of view On Feb 1, 2014, at 7:09 AM, Pharo4Stef <pharo4Stef@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
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. 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. Therefore: please stay on topic and stop arguing by pointing to visions because it will move us away from the original discussion and one can easily get the impression that opposite opinions on the topic are cut down as if people are either grumpy old Smalltalkers or betrayers on the Pharo movement - which is simply not the case! So lets continue discussing about the topic - because I see no violation agains the Pharo vision here. ---------------- 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. 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. 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. Music is still lowered and ears are all open... Thx T.
On Feb 1, 2014, at 12:39 PM, "Torsten Bergmann" <astares@gmx.de> wrote:
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
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.
Torsten I love the changes of Johan. I would love to have a more compact class definition :) Now the question by henrik is really puzzling me. Stef
Hi Johan,
Still I really do not understand what particular problem that is solved by changing the template from
MySuperclass subclass: #Foo instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Bar-Core'
to
MySuperclass subclass: #Foo instanceVariableNames: '' classVariableNames: '' category: 'Bar-Core'
other than some of your student had problem not yet knowning what pool dictionaries are and you want to hide pools therefore. A weak argument since some students may not yet know about class variables - so why not hiding them in the first place too?
Another teacher may argue that his students got problems because the template was changed and nearly all ST, Seaside and Pharo books used for teaching include the extended variant of the message.
IMHO a class template is (as the name says) a "template" and a template should be something one just has to fill out. The idea of a template is to avoid too much typing afterwards. So the idea is one just should fill out the template without much hazzle. If I require an ivar, a class variable, a pool or a category I just put it in.
By now reducing the template people who require pools have to do more typing and they have to remember the order of words in the keyword message...
I stand at my point I think there is not much real value in this change of the default template, but are fine if community agrees on the reduced version.
Thanks T.
On Jan 31, 2014, at 2:19 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
I love the changes of Johan. I would love to have a more compact class definition :) Now the question by henrik is really puzzling me.
But is not working, isnât it? I mean for the people. I donât want to be critical here, only to analyse this case of decision process because on the heat of the trenches this things are easy to miss... Imagination is not market fit. Before deciding to break tradition, shouldnât validation come first? If so, our method to make decisions risks to be overexposed to audience misfits. Misfitting the statu quo is okay, misfiting your audience one too many times is a formula to end up alone (AKA having a product nobody wants to use). Lets say you have an idea to innovate on UI or the API... you can go ahead and prototype how it feels for yourself even a partially implemented draft of the idea (lets say a branch). 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. So to yourself the hard and useful questions: Do they validate? signals of market fit? are they strong? convincing? are they weak? so are they worth now? are you sure they are being honest and not saying yes just to be nice, to please you? When you donât validate youâre doing software for yourself in front of others. Thatâs cool until is not. What are Pharo's usage metrics these days? sebastian o/
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@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
On Feb 1, 2014, at 11:37 AM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
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.
Yeah we are totally exposed to the problem of having ~null usability tests so our UI are non-designers attempts to get it incrementally right Thatâs a hard one. We really need help from design universities students
On Feb 1, 2014, at 10:58 AM, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Feb 1, 2014, at 11:37 AM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
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.
Yeah we are totally exposed to the problem of having ~null usability tests so our UI are non-designers attempts to get it incrementally right
Thatâs a hard one.
We really need help from design universities students
Yes, something like this would be great. If it's a consolation: this kind of problem is present throughout the programming language research community. There's a great paper by Hanenberg on that. It's called "Faith, hope, and love: an essay on software science's neglect of human factors". (OOPSLA 2010) Well worth the read! ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
On Feb 1, 2014, at 12:09 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Yes, something like this would be great. If it's a consolation: this kind of problem is present throughout the programming language research community. There's a great paper by Hanenberg on that. It's called "Faith, hope, and love: an essay on software science's neglect of human factors". (OOPSLA 2010) Well worth the read!
thanks for the reference Johan. Introducing mature slots in a clean easy to understand UI is great. My problem is with introducing innovation poorly It can be traits, new API, you name it
On Thu, Jan 30, 2014 at 11:42 PM, Torsten Bergmann <astares@gmx.de> wrote:
Please make it a setting - so one can see the creation message with poolDictionaries in Nautilus as before in the browser and is able to fill out the template.
When using NB one requires them.
Well, since it seems that the direction is to auto-hide the poolDictionaries part (and a preference is undesirable), another option is a NB-specific browser that just always shows this keyword.
And for those (few) of us that use Traits, maybe a specific browser to include the uses: keyword as well, so that I don't have to remember where it goes when I need it in another 6 months time. But, not for Pharo3, and not from me (at least, not right right now). -cbc
Thx T.
Chris Cunningham wrote
maybe a specific browser to include...
A real UI instead of editing a string in a workspace would make these problems go away. Show a little form there, with a button or menu to show/add pool dictionaries/Traits/whatever ----- Cheers, Sean -- View this message in context: http://forum.world.st/poolDictionaries-removal-breaks-my-projects-tp4740427p... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (13)
-
Andreas Wacknitz -
Chris Cunningham -
Eliot Miranda -
Esteban Lorenzano -
GOUBIER Thierry -
Hilaire Fernandes -
Igor Stasenko -
Johan Fabry -
Lorenzo Schiavina -
Pharo4Stef -
Sean P. DeNigris -
Sebastian Sastre -
Torsten Bergmann