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