[squeak-dev] The Inbox: Tools-LM.828.mcz

Eliot Miranda eliot.miranda at gmail.com
Tue Aug 14 16:49:38 UTC 2018


Hi Florin,

> On Aug 14, 2018, at 8:03 AM, Florin Mateoc <florin.mateoc at gmail.com> wrote:
> 
>> On 8/14/2018 4:52 AM, Leon Matthes 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.
>> 
>> 
>> 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 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 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.
> 
> 
> Why don't you like the use of allInstances in this case? finding all references belongs to the same kind of meta
> programming activities as finding all instances, so if there is a case where allInstances should be used, it is exactly
> something like this

The point is that the garbage collector is not eager.  A reference counting GC can be eager, except in the collection of cycles.  Practical implementations almost always include some form of deferment, such as Peter Deutsch’s Deferred Reference Counting, which defers counting the stack until a fixed sized zero count table has filled up.  So in practice garbage collectors do not collect all garbage immediately.  But allInstances indiscriminately trawls the heap, potentially reviving otherwise inaccessible objects that are yet to be collected.  In this case these objects can’t possibly prevent GC, so they’re spurious.  In this case it does no harm (a false positive of something that should be excluded has no effect on the pointer search).  But it’s still potentially go gust by and, as I said, slower to compute than traversing my the scene graph.

This last point is important.  With 64-bits we can have apps with huge heaps and a PointerFinder may be a very important tool in fixing storage leaks within them.  Even more important then that time not be wasted using a catch all like allInstances to kick off a search. 

> Regarding the previous issues discussed, I agree that #ifTrue: is not obvious. More than that, I have seen many bugs
> caused by people not realizing that it would sometimes return nil, even if the block would always return something
> notNil. So I would argue against brevity in this instance, I think
> 
>     e ifTrue: [s] ifFalse: []
> 
> would avoid these kinds of errors, so I would prefer it.

This one is more debatable, but I find it troublesome that someone would not know what the default return is.  It could be self, it could be nil, but that there is a definition is important, and it should be known.  So for me I always go for the short form.

 I think that the implementation of control structure via closures and messages is a) a core part of the system design, implying extensible control structures, deeply elegant and informed by computability theory, b) foundational to the system, both in the system being built upon these control structures, and in their definition being included in the system, and, with sufficient effort, actually extensible (see Marcus Denker’s magnificent mustBeBooleanMagic: in Pharo), b) beautifully concise; one can read the entirety of Boolean, True and False in a few minutes and the insight it gives into system design is enormous.  I still remember the thrill of getting it for the first time.  A teacher of Smalltalk should strive to give their students that same thrill.  This is one of the most profound and beautiful parts of the system and of computing.  The curly bracket languages are so weak in good part because they don’t embody this.

> But I would also argue against [nil]. It is true that Smalltalk was meant to be very readable and approachable, not just
> by beginners but by children, and it is not an accident that it reads so much like "normal" English.
> 
> Still, blocks are not English-like, they are one of the constructs that do need to be learned. And I have never seen
> bugs caused by ifAbsent: []. If it is not obvious what ifAbsent: [] does, the reader would be driven towards looking at
> what an empty block returns, and they would learn it at that [point, as they should, even if they did not remember it
> initially from when it was taught.

*1

>> Kind regards,
>> Leon
>> 
>> 
>> 
>> --
>> Sent from: http://forum.world.st/Squeak-Dev-f45488.html


More information about the Squeak-dev mailing list