Shorthand for "function" keyword

Laurentiu Taschina source.spider at gmail.com
Sun Nov 12 04:00:32 UTC 2017


> The only benefit seems to be saving a few characters. The costs being an
increase in complexity in the ways you can define a function, an increase
in the complexity of parsing for functions, and the need to endure a
candidate stage process for the removal of a few characters. To me, the
costs far outweigh the benefit of just using the existing ways of declaring
functions.

I believe you're being unfair here. It's obviously not just 4 characters
when it's such a common construct. If "let" was 3 words instead of 3
letters, like say "assign variable value" what do you think would happen?
Would people think of it as "just 18 more characters". No, people would
ignore it completely no matter it's usefulness or correctness and world
continue to use "var" exclusively.

The cost of not changing it is that people will slowly and surely gravitate
to avoiding using "function" ever (if they can), and thus the construct
that can be named falls out of favor. And history has shown it happens,
particularly in javascript, given the popularity of $ and _ for a good
number of libraries, and at the same time the unpopularity of perfectly
usable but tooLongToTypeNamed native versions. Of course in large part it's
ease of use and consistency and all that, but the first thing I ever hear
they being sold on is how short/easy they are. Looking at other cases today
you have the situation of things like Kotlin vs Java, or swift vs objective
C. From Kotlin's site it literally gets described as "Concise, simple and
very easy to read (and write)" in their first example. But even looking at
just javascript's past, people clearly care enough to make their own
divergent language just to get it have things be shorter—and if they can't
do that, then the next best thing is to misuse the language.

This wouldn't maybe be a particular big issue, but javascript is
more-or-less "build complex functions with a bunch of small functions."
Callbacks imply lots of functions, promises imply a lot of functions,
functions are usually split into lots of smaller single-use-functions,
functions often times return functions, etc.

Anonymous functions are already kind of annoyance born of laziness but with
arrow functions (and how they can not easily have a name in the context of
a callback) they're becoming particularly routed into the language. I think
at this point people looking at a stack trace seeing the callbacks named
will look at it as something strange. Don't you think that it's strange
that that's normal?

With regard to the difficulties of this going though, I could have
presented the some-greatest-feature-ever and you could have just
copy/pasted that 2nd part of your sentence there to shoot it down. All I'll
say is that it's just a synonym to an existing thing (even let is more
complex), for users it's just an nicer version that helps with moving away
from anonymous functions (you wouldnt really ever need to use "function"
ever again, much like you dont need "var" now). And as far as implementing
goes, if we were to create javascript form scratch would we actually use
"function" as the keyword for creating functions and all the other
overlyLongMethodNames? I don't think so, every other programming language
doesn't seem to think so, with how concise most libraries are written the
community doesn't seem to think so, and even the language javascript
presumably copied those habits from probably no longer thinks so anymore. I
think even with out other benefits just getting closer to the language that
everyone thinks it should have been like is valuable enough to warrant the
hassle. I assume that's the very reason we have let now too.


On Sat, Nov 11, 2017 at 1:00 AM, Eli Perelman <eli at eliperelman.com> wrote:

> > I'm having trouble believing saving a couple of characters will have
> the weight to make it happen
>
> I think this is the crux of the issue. What is the cost vs. benefit of the
> proposal, and do these benefits outweigh the tradeoffs?
>
> The only benefit seems to be saving a few characters. The costs being an
> increase in complexity in the ways you can define a function, an increase
> in the complexity of parsing for functions, and the need to endure a
> candidate stage process for the removal of a few characters. To me, the
> costs far outweigh the benefit of just using the existing ways of declaring
> functions.
>
> TLDR; to me this is -1.
>
> Eli Perelman
>
> On Fri, Nov 10, 2017 at 4:51 PM T.J. Crowder <tj.crowder at farsightsoftware.
> com> wrote:
>
>> On Fri, Nov 10, 2017 at 7:25 PM, Laurentiu Taschina <source.spider at gmail.
>> com> wrote...
>>
>> So the TL;DR of all that is: You think `func` (or whatever) can be an
>> identifier or keyword based on context.
>>
>> Well, quite true, it's certainly been done before (`async` for instance).
>> All I'll say is: Good luck with that, for this purpose. :-)
>>
>> I'll flag up an ASI gotcha you'll need to avoid: When defining `func`
>> function definitions, you'll need "[no LineTerminator here]" after the
>> closing `)` of the parameter list. Why? Because otherwise this is a
>> function call followed by a standalone block thanks to ASI:
>>
>> ```js
>> let a = func()
>> { console.log("blah"); };
>> ```
>>
>> (Which is why AsyncFunctionDefinition has "[no LineTerminator
>> here]" after `async`.) But again: It's been done before, so...
>>
>> I'm having trouble believing saving a couple of characters will have the
>> weight to make it happen, and personally wouldn't favor it, but frankly
>> that doesn't mean anything.
>>
>> -- T.J. Crowder
>> _______________________________________________
>> 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/20171112/d135602a/attachment-0001.html>


More information about the es-discuss mailing list