Re: Why, for example, maps but array?

On Sun, 15 Aug 2021 13:57:42 +0900
zxq9 <[email protected]> wrote:

> One layer is the semantic choice of "does the name of this module
> indicate that this modules 'deals with Xs' or does it represent *a*
> single X when the user is typing it?"

Or neither:

Implementation layer:
I am working on 'the module that deals with Xs', or on 'the map module'?
OO? 'represents one'? class CollectionOfXs but not CollectionsOfXs,
or Xcollection

On the application level, in, say:

    ... = lists:filter(...)
    ... = maps:filter(...)

the name only makes the function name more
specific by evoking some mind context (and for the compiler too).

* division -> integer division (for all of them)
* tree -> apple tree (no matter whether with 0, 1, 2, ... apples)


> I like it when the naming semantic for the interface module to an X is
> singular. It makes sense to me as a user of that module to say
> `map:find(Key, Map)` rather than `maps:find(Key, Map)`, but also makes

And others do like the opposite and cannot see any sense.
The question is: why?


> sense to have a separate module called actually `maps` for things like
> the "List of Maps" module that I wrote a while back that was recently

And `list_of_maps` is not `lists_of_maps`, and:
* tree dealing with the production of apples -> appletree;
* lom/map_list -> lom/motor_bike?!
* PLIST, ALIST, proplist, List of maps -> maplist.

OC, proplist is jest: it would pretend to somehow restrict
associations or pairs to be properties.


> probably under a different name). https://gitlab.com/zxq9/lom

Good choice! (prejudice after two clicks)
The pain of creating a µsoft github account is still fresh.
The PR-speak, the bloat, that yucky Di$ney-ic imp
made me wish that it had not been the web page I was looking for.

Is collaboration between micro$soft github and gitlab practicable?
(... and will it remain so? ...)


> These semantic sort of things are quirks and no guideline for
> formalizing them has been fleshed out.

do_pseudo
    look > see > choose
    if test emergency -or urgency
    then toss coin
done


> Argument order regularity is also  a bit of a crap shoot
> throughout the stdlib, but over time you sort of learn it and stop caring.

Yes, everyone can learn that, and this:
    there /= their /= they're,
and
    your /= you're,
and
    than /= then,
and
    and the rest of English orthography,
and
    the fun of German noun classes (genders),
and
    German inflexions,
and
    then:
they cannot, or only brokenly, and with _constant_ effort,
even if no longer aware of it because of practice.
And they have to! but only because everyone always tells them
that everyone can learn that ...


> Fixing this stuff up would be cool, but takes a huge amount of effort

There will be no consistency.
It is enough to improve decisions taken now:
* there will be more modules than there are now;
* there will be more programmers than there are now.

あいがとう

~Michael

--

    hexadecimal | decimal | octal | dual | binary

Which one sticks out like a man in a Robin Hood costume,
standing in the middle of a pond with a wooden duck on his head?