Hi Leon,

> On Aug 14, 2018, at 1:52 AM, Leon Matthes <leon.matthes at student.hpi.de> wrote:
> 
> In the interest of full disclosure, I should probably first tell you, that I
> am the original author of the commit and I actually am one of Tobias
> students and are now at about one year of squeak/smalltalk experience and up
> until a few days ago fell right in the middle of the 95% of students who
> didn't know for certain that [] == nil is true.

I do not mean this as a personal attack.  You are clearly a strong programmer and I am grateful for your participation and contributions.  I hope that you will see my critique of one tiny part of a valuable commit as a plea to avoid a slippery slope, not an attack in your abilities.  You have proven your abilities.  My concern for where the slope leads is speculative and perhaps I am wrong, but I think my concern is valid.  I hope to persuade you below.

> Eliot Miranda-2 wrote
>> That way leads to American English...or Newspeak (Orwell) ;-)
>> 
>> Seriously, there is a flaw in the teaching if your figures are right. 
>> Literacy is important.  Brevity is important. Idiom is important.  And
>> knowing what the basic elements of the language are is important.  That []
>> value == nil is true is important.
> 
> I was very likely once taught that [] == nil is true, but it is just
> something that comes up so rarely, that I just forgot about it.
> I did actually check the implementation to make sure, it is true, as I
> suspected, but because it is important for the algorithm in question I
> wanted to make sure everyone can understand the code, even if they don't
> have much experience with smalltalk. In my personal opinion, easy
> understandability, even by newcomers is more important than brevity, because
> otherwise you will just scare people away from the language, if you first
> need to study it for years on end before you can sufficiently read it.
> If brevity is important to you however, I would suggest a middle ground of
> "obj := parents at: obj ifAbsent: nil" as a compromise.
> nil is just one more character than [], but more clearly represents the
> intent.
> But this solution is indeed less idiomatic, therefore I'm not really
> satisfied with it either, I would like to hear someone else's stance on it
> however.
> 
> 
> Eliot Miranda-2 wrote
>>>> Another thing one should know is that 
>>>>   e ifTrue: [s]
>>>> is the same as
>>>>   e ifTrue: [s] ifFalse: []
>>>> etc. ie, if e is false the value is nil.
>>> 
>>> You know that I did not know that five years in into using Squeak (that
>>> is when I started implementing for my master's thesis)?
>> 
>> Did you never read the definitions for ifTrue: and ifFalse: ?
> 
> I did read them in my first few weeks of study and was amazed that you could
> actually look into the definitions of such primitive procedures but again,
> its just something thats almost never important, and therefore not
> necessarily something to actively remember.
> 
> 
> Eliot Miranda-2 wrote
>>> It's only obvious in hindsight. I had rather expected to
>>> 
>>>   e ifTrue: [s]  ===> false OR s
>>> 
>>> Which is an equally sensible variant.
>>> 
>>> I don't want wo argue that things are bad. but let's not go down that
>>> road and say One Must Know That ... :)
>> 
>> But yes, one /should/ know that.  The core classes should be read.  If you
>> want to raise a generation of JavaScripters then sure, ignore literacy. 
>> But if you want to raise a generation that can appreciate great, carefully
>> considered design, educate them to think and to read and write well. 
>> Everything else is Ebonics and the Prussian Model.
> 
> Again, one probably should know that, if one is a long time smalltalk
> developer but there are always people that don't. Maybe its because they
> just started squeak/smalltalk, or never got around to reading those few
> particular methods. In any case, I think we should always include the people
> that don't know every nook and cranny of the language they are working with,
> because otherwise we would neglect new programmers, who are just so very
> important for the health of a language.

I disagree strongly that we should always include “the people
that don't know every nook and cranny of the language” for several reasons.  First, knowing that [] == nil is true is foundational.  It is extremely common.  If one does not know that [] == nil then there is lots of code in the system one does not understand.  You might  count the number of occurrences of [] and [nil].  One can always posit an ignorant programmer.  But whereas ignorant programmers can be enlightened, or better still enlighten themselves, a language that falls into disrepair maybe irretrievably damaged.  I grew up in Britain speaking British English and I live in the United States and am occasionally shocked by the loss of precision in the use of English here.  It has real effects.  Lots of people in the US think that “inflammable” means “cannot burn”; it means the opposite.

Would not the effect of failing to maintain high standards of literacy in a communal programming system is increasing doubt and uncertainty in the community members and verbosity and higher maintenance costs in the code?

A number of far greater thinkers than I have made simplicity a foundational principle. William of Occam stated, Non sunt multiplicanda entia sine necessitate (Entities are not to be multiplied without necessity).  It is attributed to Einstein that “all things should be made as simple as possible – but no simpler”.  And then there’s KISS (Keep It Simple, Stupid”.

Does this apply to [nil]?  Maybe not.  But what’s your reaction to those who fail to use der, die, das, dem & den correctly?  Do you feel that the person has something to learn or that German should be bastardized to compensate for their failings?

> I would be interested though why you think extreme brevity is so crucially
> important, because I often don't see the use of it, except that its a little
> less typing, so maybe I'm missing the point here.

I don’t value brevity in this case. I value not obscuring basic semantics.  I value a shared language that increases in beauty, not lessens.

> 
> I would also appreciate feedback on this small piece of code:
>    + PointerFinder on: self object except: {self}, ObjectExplorerWrapper
> allInstances! 
>    - self flag: #tooMany. "mt: Note that we might want to ignore references
> caused by this tool." 
>    - self object chasePointers.! 
> I really don't like the use of allInstances in this case, but I didn' see a
> better way to find the ObjectExplorerWrappers that might hog references to
> the Object in question.

Traverse the world looking for submorphs whose models are ObjectExplorers and collect their ObjectExplorerWrappers.  The use of allInstances is indeed wrong.  Look also for Inspectors.  A PointerFinder or Inspector could indeed be the object holding onto something that should be garbage collected, and these UI objects can become disconnected from the scene graph, for example left in some global variable during a debugging session.  But think carefully about the criteria for choosing which PointerFinders and Inspectors are considered excludable; does one include those in different projects?  What about ones that are hidden or partially obscured behind other windows?

In general be suspicious of allInstances.  It is appropriate for schema evolution, where it is essential that every object of a particular class change shape, but for finding things, graph traversal is always going to be faster, and allInstances may uncover zombie objects that the garbage collector has yet to reclaim.  Test by timing collecting all instances of CompiledMethod and timing finding all CompiledMethods by traversing from Class rootsOfTheWorld.

> Kind regards,
> Leon

Regards to you.  Apologies for being a pedantic old man ;-)

> --
> Sent from: http://forum.world.st/Squeak-Dev-f45488.html