Proposal: Selector/Select Expression

guest271314 guest271314 at gmail.com
Sun Jun 23 02:38:52 UTC 2019


>
> then we are epistemological nihilists with no criteria whatsoever on which
> to base our language design decisions and this mailing list would have no
> raison d'etre, since we would never be able to align on anything.


That can be the case. Agreement is not required by the parties for a
specification or any other document to be drafted, published, and even
enforced. Even a treaty between nation-states. The populace can absolutely
disagree with the authors of the document. One or more parties can sign but
ignore some or all sections of one or all treaties between sovereigns.

But this is no more a readability problem than the fact that one must have
> knowledge of the English worrds in a sentence in order for them to be
> "readable".


That is indeed accurate. The engish language is equivocal, capable of being
employed for deception; where there are, generally, more than one meaning
for a given word or term. The artist E-40 uses the english language in
their published work, though english professor at western academic
institution would more than likely not have any clue as to what the english
words that the artist creates, combines and uses mean whatsoever; that is,
without one or more individuals that might not have a masters or doctorate
in english supplied by an english-speaking institution of higher learning
the would-be teacher what the words and terms used by the artist mean. The
same holds true for the Ancient African Egyptian symbols and scripts, which
are claimed to have been "deciphered" by Thomas Young, Champollion, et al.
well over a thousand years after the conquest of the Ancient African
Egyptians by Alexander of Macedonia. An entire discipline ("Egyptology")
was created based on guessing and spurious manufacture after the fact. They
have no clue what the words meant to the authors of the symbols, as the
authors were never asked and the purported "Egyptologists" were never told
the meanings of the sacred symbols by the authors and builders of the
scripts and symbols. Some say "TMH" means "created white people" others say
the word means "Lybian". Since the Ancient African Egyptian language had no
vowels, the user supplies the vowels; the word can have Latin inserted to
become "TaMaHu", though since the language is sacred, the Ancient African
Egyptians never told or taught their conquerors the original meanings of
the terms, and never will. No matter how many times whomever tries to claim
they understand those scripts and symbols they can never verify their at
best guesses at worse intentional deceit. The manufactured mythologies and
outright fraud continue in any direction and field traversed when dealing
with specifically english words and terms. Therefore, the english language
is not an appropriate example to compare JavaScript, or any specified
coding langauge to.

In any event, re-read the proposal. Am certainly not opposed to the
JavaScript language being capable of golf by default. Is the gist of the
proposal to substitute ```|>```, and or ```.``` at ```const getEmail =
.contacts.email;``` as the first character after ```=``` for `=>`, meaning
the initial ```.``` following ```=``` is interpreted as a function call,
equivalent to ```=>```? Can you include comments next to the examples at
the OP detailing what each character is intended to mean in JavaScript,
compared to the current specification of JavaScript?


On Sun, Jun 23, 2019 at 12:13 AM Bob Myers <rtm at gol.com> wrote:

> The world is awash in subjectivity.
>
> We can nevertheless hope to find broad agreement on at least a transitive
> ranking of attributes such as readability; if we don't think we can, then
> we are epistemological nihilists with no criteria whatsoever on which to
> base our language design decisions and this mailing list would have no
> raison d'etre, since we would never be able to align on anything.
>
> However subjective the notion of readability, I think few would disagree
> that the first fragment below is more readable than the second.
>
> ```
> .name
> ```
>
> and
>
> ```
> ({name}) => name
> ```
>
> The first is also more reliable by most measures, because it removes the
> possibility of misspelling one of the instances of ```name``` in the
> second, which we would prefer not to rely entirely opn type checkers or
> linters to pick up.
>
> Yes, to read the first does require additional knowledge, namely of the
> fact that the syntax ```<dot>property``` denotes a function to retrieve the
> value of the property by that name. But this is no more a readability
> problem than the fact that one must have knowledge of the English worrds in
> a sentence in order for them to be "readable". Such knowledge is often
> referred to by terms such as "cognitive footprint". Yes, this proposal does
> have a cognitive footprint. But all language features have cognitive
> footprints, requiring that people writing and reading code using the
> feature have knowledge of the feature. The issue then becomes the *size* of
> the cognitive footprint in relation to the benefit--an equation both sides
> of which involve subjectivity...
>
> Of course, I did not mean to imply that readability or reliability in and
> ot themselves are either necessary or sufficient for a new languge feature,
> There are many other aspects, as many as a dozen, which have been discussed
> and defined in earlier threads.
>
> Bob
>
> On Sat, Jun 22, 2019 at 12:08 PM guest271314 <guest271314 at gmail.com>
> wrote:
>
>> > If the requirement is merely to write a function to pick properties,
>> yes. If the requirement is to do that in a more concise, readable, reliable
>> way, no.
>>
>> The term "readable" is entirely subjective. As far as am aware there is
>> no standard for "readable" (in any language, coding or not). Even if such
>> criteria for "readable" did exist in some institutional document, no author
>> of code (or anything else) is bound to recognize or adhere to any such
>> subjective and arbitrary criteria.
>>
>> What specific definition of "reliable" is being used, and what are the
>> cases that demonstrates using destructing assignment is not "reliable"?
>>
>> On Sat, Jun 22, 2019 at 6:50 PM Bob Myers <rtm at gol.com> wrote:
>>
>>> On Sat, Jun 22, 2019 at 10:59 AM guest271314 <guest271314 at gmail.com>
>>> wrote:
>>>
>>>> Does not destructuring assignment provide a means to achieve the
>>>> requirement?
>>>>
>>>
>>> If the requirement is merely to write a function to pick properties,
>>> yes. If the requirement is to do that in a more concise, readable, reliable
>>> way, no.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190623/36a72b66/attachment-0001.html>


More information about the es-discuss mailing list