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