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