es-discuss Digest, Vol 107, Issue 53

Robin Cafolla robin at zombiemongoose.com
Sat Jan 23 20:30:20 UTC 2016


I think having some simple way of getting the last element would be a long
time coming to JS. You really shouldn't need to type arr[ arr.length - 1 ]
every time you want the last element. I don't care if it's .last() or .nth(
-1 ) or .end() as long as it's something short and memorable.

Remember, this is something you do all the time. Imagine the amount of
productivity lost by all JS developers by having to type out
myActualVariableName[ myactualVariableName.length - 1 ] every time...
You're talking millions of dollars worth of wasted effort.

End the madness now!

</rant>

On 23 January 2016 at 19:56, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>    1. Re: JavaScript Language feature Idea (Bob Myers)
>    2. Re: JavaScript Language feature Idea (kdex)
>    3. Re: Extending spread operators to work with numbers
>       (Mark S. Miller)
>    4. Re: JavaScript Language feature Idea (Micha? Wadas)
>
>
> ---------- Forwarded message ----------
> From: Bob Myers <rtm at gol.com>
> To: kdex <kdex at kdex.de>
> Cc: es-discuss at mozilla.org
> Date: Sat, 23 Jan 2016 18:01:24 +0530
> Subject: Re: JavaScript Language feature Idea
> On Sat, Jan 23, 2016 at 12:54 PM, kdex <kdex at kdex.de> wrote:
>
>> [1, 2, 3].last();     // 3
>
>
> I'm wondering what the ultimate motivation for suggestions like this is.
> Is it to save key strokes? Allow more semantic coding? Support new
> paradigms? Performance? 'm sure someone has already come up with a good
> categorization like this, would someone mind providing a link? Could one of
> these be considered the "theme" for the next version?
>
> I have to admit to be being quite negative about proposals of the form
> "Hey, this other language does X, can we do that too?", or "It would be so
> cool if we could do Y", especially when these are mostly about syntax. Is a
> missing `last` really one of our painpoints?
>
> Bob
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: kdex <kdex at kdex.de>
> To: Bob Myers <rtm at gol.com>
> Cc: es-discuss at mozilla.org
> Date: Sat, 23 Jan 2016 17:32:20 +0100
> Subject: Re: JavaScript Language feature Idea
> Not every feature addition is due to performance or paradigms. Just have a
> look at ES2015: I'm sure that this has neither been the motivation for
> `String.prototype.startsWith`nor for `String.prototype.includes`. Even
> `String.prototype.repeat` appears so simple that a loop paired with a
> concatenation could have become a popular alternative.
>
> Of course you could solve most of these string problems with earlier
> versions
> of the language, too, often explicitly thinking with incides. But on the
> downside, your code suddenly becomes a potentially unintuitive,
> index-ridden
> mess, introducing off-by-one and out-of-bound errors (it even happened to
> someone on this thread, too, if you review Thomas' code from above). This
> isn't really all too much about saving keystrokes, but mainly about writing
> clean, readable and maintainable code.
>
> There's array::back in C++, negative indices in Python as well as Bash or
> end
> in PHP, so I don't see any reason why we should complicate things for
> people
> coming from these languages. Nor to I see why we should torture ourselves
> thinking about how the underlying data structure stores its elements
> internally when all I care about is reading the last element.
>
> Just ask yourself: Do you think it's substantially more readable to write
>
> ```js
> [1, 2, 3].slice(-2)[1];
> ```
> over
> ```
> [1, 2, 3].last(1);
> ```
> ?
>
> If it comes to write access,  I agree that`Symbol.last` could be another
> handy
> addition (it doesn't have to be an "either/or" discussion, really):
>
> [1, 2, 3][Symbol.last]; // 3
> [1, 2, 3][Symbol.last] = 4; // 4
> [1, 2, 3].last(1); // 2
>
> On Samstag, 23. Januar 2016 18:01:24 CET Bob Myers wrote:
> > On Sat, Jan 23, 2016 at 12:54 PM, kdex <kdex at kdex.de> wrote:
> > > [1, 2, 3].last();     // 3
> >
> > I'm wondering what the ultimate motivation for suggestions like this is.
> Is
> > it to save key strokes? Allow more semantic coding? Support new
> paradigms?
> > Performance? 'm sure someone has already come up with a good
> categorization
> > like this, would someone mind providing a link? Could one of these be
> > considered the "theme" for the next version?
> >
> > I have to admit to be being quite negative about proposals of the form
> > "Hey, this other language does X, can we do that too?", or "It would be
> so
> > cool if we could do Y", especially when these are mostly about syntax.
> Is a
> > missing `last` really one of our painpoints?
> >
> > Bob
>
>
>
>
> ---------- Forwarded message ----------
> From: "Mark S. Miller" <erights at google.com>
> To: John Gardner <gardnerjohng at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Date: Sat, 23 Jan 2016 10:41:43 -0800
> Subject: Re: Extending spread operators to work with numbers
> The double dot ("..") is the traditional infix operator for
> inclusive,inclusive integer ranges, going back to Pascal (the language, not
> the mathematician). This has all the benefits you seek, including visual
> clarity, without overloading the meaning of an existing token.
>
> Whether double or triple dot, the problem is that programming patterns in
> zero-index-origin languages want inclusive,exclusive ranges, which
> naturally wants an asymmetric syntax to suggest the distinction. The
> traditional math notation [0, 4) would be unambiguous, since of course we
> never otherwise allow a closing paren to match an opening square bracket.
> But, in a programming language context I find it too jarring.
>
> E has ".." for inclusive,inclusive ranges, just like Pascal. E also has
> "..!" for inclusive,exclusive ranges. The second operator was used much
> more than the first. I don't think "..!" is great but I don't have anything
> better to suggest.
>
> Finally, we must ask whether this problem is worth solving with any syntax
> or at all. We can already express these well enough with APIs. I think this
> is one of those issues where the benefit of any new syntax here does not
> pay for its complexity costs. See *The Tragedy of the Common Lisp, or,
> Why Large Languages Explode* <
> https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks
> >.
>
> See also <https://en.wikipedia.org/wiki/Primum_non_nocere>.
>
>
>
>
>
>
> On Fri, Jan 22, 2016 at 10:20 PM, John Gardner <gardnerjohng at gmail.com>
> wrote:
>
>> Probably a stupid idea, and I can see it already being brought up several
>> times... but why not extend spread operators to work with numeric ranges?
>>
>> let a = [ 0 ... 3 ];
>> // Expands to: [ 0, 1, 2, 3 ]
>>
>> This wouldn't be a groundbreaking feature, but it would allow better
>> readability when plotting a range of values:
>>
>> let esVersions = [ 1 ... 5, 2015 ];
>>
>> It might also be used to extract a range of values:
>>
>> array[ 3 ... 6 ] = "ABCDEFGH";
>> // [ "D", "E", "F", "G" ]
>>
>> Which I find far more readable than this:
>>
>> array[ , , , , 3, 4, 5, 6 ] = "ABCDEFGH";
>>
>> Since it would require two numbers to be explicitly supplied on each
>> side, there's no risk of it being misinterpreted as an attempt to spread an
>> array. Decimal components would be dropped:
>>
>> let a = [ 1 ... 3.9 ];
>> // [ 1, 2, 3 ]
>>
>> This would complement Alican's suggested syntax for slicing an array of
>> values, which modifies the original array.
>>
>> Thoughts? Just throwing crap out there.
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
>
> ---------- Forwarded message ----------
> From: "Michał Wadas" <michalwadas at gmail.com>
> To: kdex <kdex at kdex.de>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Sat, 23 Jan 2016 20:56:02 +0100
> Subject: Re: JavaScript Language feature Idea
> I can't consider `.last(1)` method to be readable...
> But I think `.nth(n)` method with support for negative index would be
> really useful.
>
> 2016-01-23 17:32 GMT+01:00 kdex <kdex at kdex.de>:
>
>> Not every feature addition is due to performance or paradigms. Just have a
>> look at ES2015: I'm sure that this has neither been the motivation for
>> `String.prototype.startsWith`nor for `String.prototype.includes`. Even
>> `String.prototype.repeat` appears so simple that a loop paired with a
>> concatenation could have become a popular alternative.
>>
>> Of course you could solve most of these string problems with earlier
>> versions
>> of the language, too, often explicitly thinking with incides. But on the
>> downside, your code suddenly becomes a potentially unintuitive,
>> index-ridden
>> mess, introducing off-by-one and out-of-bound errors (it even happened to
>> someone on this thread, too, if you review Thomas' code from above). This
>> isn't really all too much about saving keystrokes, but mainly about
>> writing
>> clean, readable and maintainable code.
>>
>> There's array::back in C++, negative indices in Python as well as Bash or
>> end
>> in PHP, so I don't see any reason why we should complicate things for
>> people
>> coming from these languages. Nor to I see why we should torture ourselves
>> thinking about how the underlying data structure stores its elements
>> internally when all I care about is reading the last element.
>>
>> Just ask yourself: Do you think it's substantially more readable to write
>>
>> ```js
>> [1, 2, 3].slice(-2)[1];
>> ```
>> over
>> ```
>> [1, 2, 3].last(1);
>> ```
>> ?
>>
>> If it comes to write access,  I agree that`Symbol.last` could be another
>> handy
>> addition (it doesn't have to be an "either/or" discussion, really):
>>
>> [1, 2, 3][Symbol.last]; // 3
>> [1, 2, 3][Symbol.last] = 4; // 4
>> [1, 2, 3].last(1); // 2
>>
>> On Samstag, 23. Januar 2016 18:01:24 CET Bob Myers wrote:
>> > On Sat, Jan 23, 2016 at 12:54 PM, kdex <kdex at kdex.de> wrote:
>> > > [1, 2, 3].last();     // 3
>> >
>> > I'm wondering what the ultimate motivation for suggestions like this
>> is. Is
>> > it to save key strokes? Allow more semantic coding? Support new
>> paradigms?
>> > Performance? 'm sure someone has already come up with a good
>> categorization
>> > like this, would someone mind providing a link? Could one of these be
>> > considered the "theme" for the next version?
>> >
>> > I have to admit to be being quite negative about proposals of the form
>> > "Hey, this other language does X, can we do that too?", or "It would be
>> so
>> > cool if we could do Y", especially when these are mostly about syntax.
>> Is a
>> > missing `last` really one of our painpoints?
>> >
>> > Bob
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160123/59de35cb/attachment-0001.html>


More information about the es-discuss mailing list