> 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 <[email protected]> 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@farsightsoftware. > com> wrote: > >> On Fri, Nov 10, 2017 at 7:25 PM, Laurentiu Taschina <source.spider@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 >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
