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 <[email protected]> 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. >
