Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision

Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-05-10 15:12:34

2011/5/8 Gottlob Frege <gottlobfrege_at_[hidden]>:
> On Wed, May 4, 2011 at 10:27 AM, Joachim Faulhaber
> <afojgo_at_[hidden]> wrote:
>>
>> ... I can not compare my auditive experience to yours because my
>> "spoken operatorish" is in German ;-) which is also pretty bizarre,
>> because c++ spoken by Germans it is a wild mixture of German and
>> English words and typically operators are spoken in German by German
>> c++ narrators. This happens in a way as if, in the face of reading c++
>> operators the human brain degenerated to a lexical scanner that scans
>> the tokens and translates them (using mother tongue) in those words
>> sequentially that it has most frequently been drilled to use for the
>> respective digits.
>>
>> As stated on the outset, this operatorish narrator produces seemingly
>> natural results e.g.
>> UK plus-equals
>> DE plus-gleich
>> for += that seems to be "paralell natural" for the two languages,
>>
>> but I have heard it producing cumbersome names like
>> DE Prozent-gleich for %=  or
>> DE Doppelpunkt-gleich for :=  (not c of course)
>>
>> because it seems not to "think" very much ;)
>> Since no one ever says "modulus" for % in Germany, but everyone says
>> "Prozent". Everyone would say
>> DE Prozent-gleich for %=
>> which would be 'percent-equals' in English.
>
> I tend to call it - or at least speak it - percent-equals as well,
> although I might not want to use that as the name in this library - it
> could be confused with an operation that actually calculated
> percentages.  Although, I guess since operators can be overloaded, in
> some sense the symbolic name "percent" is more accurate than how it
> operates on integers.  x % y doesn't mean modulus for arbitrary
> classes.  Maybe it does calculate percentages.

operator %=
is a good example that "spokenness" and "common calledness" can be
rooted in unsystematic decisions and historic choices that have not
been done from an intention of consistent, intuitive and semantically
sound naming for operators. Someone decided to attach the modulus
operation to % and "assign-modulus" to % and %=

(1) We spontaneously speak percent-equal
(2) We might even call it an operator percent-equal, when talking
about it but we
(3) dislike percent_equal or percent_assign as the operator's name
within a boost library, ... why?

because it is obviously inconsistent with
(a) the default semantics for operator %= in c++
(b) the existing standard name for %-wrapper-functor modulus

As stated before, "spokenness" seems to produce clumsy results,
because it tends to combine names for lexical tokens without any
reflexion and thinking. In contrast, names from boost libraries and
even more so from the standard need to pass a process of thinking,
sometimes discussion (like this one) and an informed decision finally.

>> I see three Problems with your Spokenness Paradigm
>>
>> (1) Spokenness of operators leads to non systematic sometimes awkward
>> conglomeration of parts.
>> (2) There are loads of differences of spoken operators in different languages.
>> (3) Spokenness as a guideline is again not consistently used.
>> Specifically not used consistently within column A
>>    We would, for example, need to name pre_increment as pre_plus_plus
>
> Ah, but no one calls it pre-plus-plus.

In my experience it is
spoken: plus-plus
called: (1) plus-plus-operator (omitting the pre post attribute) and also
        (2) (pre/post)-increment-operator

> This is where spokenness and
> common usage diverge.  We call it pre and post increment when we need
> to differentiate.  If it was understood in context, I would explain to
> someone that "a list iterator overrides operator plus-plus to move to
> the next node in the list".  But if I needed to give someone a task, I
> would probably be more precise - "you need to use pre-increment here,
> as it tends to be more efficient...".  Etc.
>
> This, I think, is an important point.  Possibly more important than
> "spokenness".  I think we, for the most part, have already decided the
> names of these operators.  By "we" I mean programmers at large.  I
> mean common usage.  Now maybe it is hard to measure common usage
> (maybe tallying google search results would help), but I think common
> usage has already decided it.  (And yes, google says "plus equals" is
> 10x more common than alternatives)

Googled today:
    85,400 "plus equals"
     8,110 "plus assign"
   355,000 "add equal"
42,800,000 "add it"
   589,000 "add it up"
    55,100 "percent equal"
     3,670 "modulus equals"

> So it has already been determined
? ;-)
via google?  Ok, everything is determined today by google, of course :)

BTW add-it-up is kind of nice ... (but it's not a MUP so I won't propose it)

> via the genetic algorithms of programmers using terms and having some
> catching on and others not.

[Ok, ... forgive me my irony ...]

I get your point and I think it is a good one. If I understand you
right you say.
(1) There is a common usage, that emerged through genetic (or memetic)
evolution.
(2) This common usage is the *best choice* for the operator names.

I continue this reasoning ...
... because from the perspective of
(1) usablility
(2) memorability
(3) ease of perception
(4) least astonishment
it is the best choice to use those names that *are* THE common sense.

What I like about this reasoning is that is proposes to let the choice
be made in acknowledgement of a larger view or context. It is similar
to what I am proposing. Only the contexts are different. Both
proposals are claiming that the choice has already been made.

(1) Tony: The choice is taken by spokenness and common usage.
(2) Joachim: The choice is taken by the standard and prevailing
(boost) libraries.

End of part I. (To be continued ;)

Cheers,
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de