[squeak-dev] The Trunk: ToolBuilder-Morphic-tpr.196.mcz

Chris Muller ma.chris.m at gmail.com
Fri Oct 6 20:54:06 UTC 2017


On Fri, Oct 6, 2017 at 1:44 PM, tim Rowledge <tim at rowledge.org> wrote:
>
>> On 05-10-2017, at 8:00 PM, Chris Muller <asqueaker at gmail.com> wrote:
>> [snip]
>> I think methods that are the most central, key abstracton of a class
>> or framework are fine candidates for a beautifully terse name and
>> comment.
>
> Well chosen terse names and explanations are fine where you are familiar with the subject, and where the potential for clashing with other areas using the same terse phrases is not an issue. There are two practical issues I see
> a) if you work in an area and use terseness as your watchword, then move off to work on another area for some time, then when you return … it’s gone. All that internalised context that made the terseness work is gone. Unless you have truly epic memory, which some people do and some don’t. I seem to work in a bunch of disparate areas on a schedule that tends to be six months here, four months there, back to here.. and it takes time to get back into the milieu every time
> b) terseness without some serious explanations somewhere easily discoverable from this terse code is inimical to newcomers.
> Oh, and looking at it another way - terseness reduces the number of bits of information offered, which is another aspect of being rude to newcomers. Even in software we need some level of social lubrication.

For example, by ignoring and even clipping the *payoff* aspect of
type-checking I conveyed, you made this reply more "terse."   :(

I think we both agree that imparting the intent of the code with low
friction is the goal.  We just have different philosophies about
whether the code, the apis, and categories, collectively, should BE
the main  conduit of understanding for the user.

I'm sure you're glad that Collection>>#do: isn't named
Collection>>#doBlock:.  That's what I meant by employing terseness
sparingly, for key methods -- something short and sweet will stand out
in the word-salad and be duly noticed.

>> Symbol is a base type!  Maybe consider relaxing your aversion to
>> type-checking for the base types at least.
>
> I disagree that there is any concept of base types here. That’s one of the great things about Smalltalk; everything is objects.

Okay, but zooming out from the "what's-great-about-Smalltalk" for a
moment to consider that real world data points have consistent
(meta)properties, is all you need to have a "group" of something.  As
an example, I'm sure you acknowledge the existence of "value" types.
Raw data types.

>>  If you ever use #isNil or
>> #ifTrue:, then you must already agree these type checks are sometimes
>> necessary.  Numbers, Strings, Arrays and, most certainly, Symbols are
>> also okay to type-check in rare, key places where it provides a lot of
>> leverage.
>
> isNil/ifTrue are not type checks, they’re value checks. true/false testing is part of the way we see control flow and we have true/false for exactly that. nil checking is a bit of a cop-out that we use because nobody has thought of a better option for handling the "if this thing hasn't been initialised yet, do some special code”.

Tim, obviously we're never getting rid of nil but.. just to challenge
your thought process...

Different, custom initializations for every var of every object?  How
would should this be controlled by the user?  "Nil" is a real world
concept anyone can understand.  How about initializing all variables
to nil, and let the user write:

    thisThing isNil ifTrue: [ self doSomeSpecialCode ]

For anthing outside the lab, nil checks and then occasional type
checks are equally essential as control flow, IMO.

> I dare say there are sophisticated things one might imagine with classes for uninitialisedFooVariableForMyPackage and .. well, who cares about details for a daft thought experiment.
>
> I don’t like stuff that smacks of type checking because it is almost always a sign pointing to poor factoring in code that never got thoroughly reviewed and fixed up.

"Almost always" depends on the code base.  I remember you mentioning
that in the Scratch code.

> Amazingly often it’s also a place where performance got gobbled up - the archetypical nasty variety of type checking is #isKindOf: and I got somewhere around a factor 10 speed improvement in Scratch just by removing the ‘need’ for half-a-dozen of them in important places. Not that I am going to claim success in being pure in this - there are still dozens or more places in the Scratch code with exactly these #isGumby checks, that will never have much hope of being removed.

Yeah, #isKindOf: is almost never justified.

 - Chris


More information about the Squeak-dev mailing list