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/20190622/876c0dc3/attachment.html>

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 on 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 words 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

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 on 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

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 on 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