Am 01.02.2014 um 15:00 schrieb Johan Fabry <[email protected]>: > > On Feb 1, 2014, at 9:32 AM, Sebastian Sastre <[email protected]> > 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
