Why, for example, maps but array?
Sat Aug 21 20:23:05 CEST 2021
On Sun, 15 Aug 2021 13:57:42 +0900
zxq9 <zxq9@REDACTED> 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?"
I am working on 'the module that deals with Xs', or on 'the map module'?
OO? 'represents one'? class CollectionOfXs but not CollectionsOfXs,
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.
look > see > choose
if test emergency -or urgency
then toss coin
> 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,
your /= you're,
than /= then,
and the rest of English orthography,
the fun of German noun classes (genders),
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.
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?
More information about the erlang-questions