> 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.

> 
> 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. 

>  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”. 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. 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.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"How many Teela Browns does it take to change a lightbulb?” 
"Stupid question."