#ast vs. #parseTree

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

NorbertHartl


Am 08.05.2018 um 05:15 schrieb Richard O'Keefe <[hidden email]>:

#gcd:
#lcm:

These come from elementary (primary school in my day) mathematics.  They are the standard names.

You mean where you live? That excludes 90% and more of the world. So when is a abbreviation ok again?

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Richard O'Keefe
First, my message was *defending* most of the short names
that someone else was attacking.  For the record, I am
*far* more worried about the fragility of typical Smalltalk
code than I am about method names, which are generally
pretty good.

Second, the criterion was implicit but fairly clear:
if an abbreviation of any kind is sufficiently common
that someone who wants the semantics will recognise the
identifier, use it.  "ulp" is MORE familiar to people
who need it than "unitOfLeastPrecision" (spit), so it is
a better name.  In the same way, HTTP is a *better* name
than HyperTextWhatever (amongst other things because the
word is Hypertext, so HyperText violates a Smalltalk style
rule that says internal capitals at *word* boundaries)
because it is familiar and takes less effort to recognise
than the fully spelled out thing.

Third, the rule as always is "intention-revealing names".
(Another Smalltalk style rule that I did not invent.)
#onDNU:do: is a confusing name because when I saw it I
expected the first argument to be a signalled exception,
not a selector.   There is nothing wrong with the DNU bit;
if you know you want to catch a DNU you are probably
familiar with "DNU" (and don't want to fuss with whether
it means Does Not Understand or Did Not Understand).
As a particular example from the list, #log or
#logarithm are both ambiguous, while #ln is NOT
ambiguous (in the context of numbers), making it a
better name,

Finally, the significant point was not where I live
(about 1/1600 of the world's population live here)
but when I went to primary school, which was somewhat
more than 50 years ago.  Twenty years before that,
children learned how to calculate square roots by hand.
(Cue Four Yorkshiremen. :-))



On 8 May 2018 at 20:00, Norbert Hartl <[hidden email]> wrote:


Am 08.05.2018 um 05:15 schrieb Richard O'Keefe <[hidden email]>:

#gcd:
#lcm:

These come from elementary (primary school in my day) mathematics.  They are the standard names.

You mean where you live? That excludes 90% and more of the world. So when is a abbreviation ok again?

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

EstebanLM
to talk seriously, I agree #onDNU:do: would be better called with its long name.
now, well known acronyms have their place in pharo as complete, self explaining method names too.

is about matter of common sense to opt for one or the other (for example, “ln" is more known in maths that its “long name" neperian logarithm). Rules and conventions are not written in stone and smart people can have an agreement on when to break them. Acronyms is this case: while *in general* using them is bad, well known acronyms as HTTP, AST, etc. are fine and even sometimes better.

cheers!
Esteban

> On 9 May 2018, at 02:03, Richard O'Keefe <[hidden email]> wrote:
>
> First, my message was *defending* most of the short names
> that someone else was attacking.  For the record, I am
> *far* more worried about the fragility of typical Smalltalk
> code than I am about method names, which are generally
> pretty good.
>
> Second, the criterion was implicit but fairly clear:
> if an abbreviation of any kind is sufficiently common
> that someone who wants the semantics will recognise the
> identifier, use it.  "ulp" is MORE familiar to people
> who need it than "unitOfLeastPrecision" (spit), so it is
> a better name.  In the same way, HTTP is a *better* name
> than HyperTextWhatever (amongst other things because the
> word is Hypertext, so HyperText violates a Smalltalk style
> rule that says internal capitals at *word* boundaries)
> because it is familiar and takes less effort to recognise
> than the fully spelled out thing.
>
> Third, the rule as always is "intention-revealing names".
> (Another Smalltalk style rule that I did not invent.)
> #onDNU:do: is a confusing name because when I saw it I
> expected the first argument to be a signalled exception,
> not a selector.   There is nothing wrong with the DNU bit;
> if you know you want to catch a DNU you are probably
> familiar with "DNU" (and don't want to fuss with whether
> it means Does Not Understand or Did Not Understand).
> As a particular example from the list, #log or
> #logarithm are both ambiguous, while #ln is NOT
> ambiguous (in the context of numbers), making it a
> better name,
>
> Finally, the significant point was not where I live
> (about 1/1600 of the world's population live here)
> but when I went to primary school, which was somewhat
> more than 50 years ago.  Twenty years before that,
> children learned how to calculate square roots by hand.
> (Cue Four Yorkshiremen. :-))
>
>
>
> On 8 May 2018 at 20:00, Norbert Hartl <[hidden email]> wrote:
>
>
>> Am 08.05.2018 um 05:15 schrieb Richard O'Keefe <[hidden email]>:
>>
>> #gcd:
>> #lcm:
>>
>> These come from elementary (primary school in my day) mathematics.  They are the standard names.
>
> You mean where you live? That excludes 90% and more of the world. So when is a abbreviation ok again?
>
> Norbert
>
>


Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

webwarrior
In reply to this post by Richard O'Keefe
Richard O'Keefe wrote
> First, my message was *defending* most of the short names
> that someone else was attacking.  For the record, I am
> *far* more worried about the fragility of typical Smalltalk
> code than I am about method names, which are generally
> pretty good.
>
> ...

If by "someone else" you mean me, I was obviously sarcastic. If you are OK
with GCD, LCM, ULP and other abbreviations, why get rid of AST? It's
well-known and unambigous term in respective area, that is also usually used
as identifier in other programming languages and libraries (e.g. ast module
in Python, Microsoft.FSharp.Compiler.Ast module in F#).




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Reply | Threaded
Open this post in threaded view
|

Re: #ast vs. #parseTree

Richard O'Keefe
I'm personally OK with 'ast'.  Did I write anything that made you
think I wasn't?

Of course things are contextual.  In VMS one took "AST" to mean
"Asynchronous System Trap".   But even in VMS it was not confusing
in a parsing context.

As for "obviously sarcastic", I'm afraid there's this thing
called "Poe's Law".

On 9 May 2018 at 23:57, webwarrior <[hidden email]> wrote:
Richard O'Keefe wrote
> First, my message was *defending* most of the short names
> that someone else was attacking.  For the record, I am
> *far* more worried about the fragility of typical Smalltalk
> code than I am about method names, which are generally
> pretty good.
>
> ...

If by "someone else" you mean me, I was obviously sarcastic. If you are OK
with GCD, LCM, ULP and other abbreviations, why get rid of AST? It's
well-known and unambigous term in respective area, that is also usually used
as identifier in other programming languages and libraries (e.g. ast module
in Python, Microsoft.FSharp.Compiler.Ast module in F#).




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html


123