Hacker News Reader

Comment by chaorace | Hacker News Reader

To go maximum pedant here, I want to say that you're somewhat conflating syntax improvements for stylistic shifts. Pre ES6 JS still allows for FP programming, so a more fair approximation of the Pre-ES6 code would be...

  var increment = [1, 2, 3, 4, 5].map( function(num){ return num + 1 } )

The two big syntactic wins of modern JS are let/const over the filth that was var and the convenience of arrow functions over anonymous function literals.

View on HN

To go maximum pedant, your `increment` is an array instead of a function which returns that array:

    var increment = function() {
        return [1,2,3,4,5].map(function(num) {
             return num + 1;
        });
    };

Moreover, modern JS is not merely convenient syntactic sugar over old JS. Let/const have different scopes, arrow functions have no bindable context.

You also now have classes, proxies, async/await, generators, destructuring, default/rest/spread parameters, ...

Add typing via jsdocs or TypeScript and - like the parent comment said - "it's really nice".

Often people mistake JS for a mere DOM manipulation language and think of

    document.getElementById('myDiv').innerHTML = 'Hello World';

instead of what it has become today.

I still hate it though for sorting arrays with only number types lexically:

    [1,2,10,20].sort(); //[1,10,2,20]

Well, not if you know that .sort(); is meant to accept a custom sort function too [1,2,10,20].sort((a,b)=>b-a)) // 1, 2, 10, 20

The issue here is that for some reason I often struggle to remember which function sorts in ascending order [(b-a) or (a-b)].

In fact, your example suffers from the same problem: It sorts in descending order (20,10,2,1) instead of ascending (1,2,10,20).

Telling JS to use a TypedArray [Int8,...,BigInt64] instead can solve this without remembering and providing your own comparator:

    Float64Array.from([1,2,10,20]).sort(); //[1,2,10,20]

I don't really understand your point of disagreement. I never claimed let/const/Arrow Functions were syntactic sugar, just that they were improved syntax. I don't see our two arguments as mutually exclusive, because I feel syntax can imply the addition of new features, as long as those features are directly tied to that syntax (by this definition, I would argue that JS classes are actually syntactic sugar, but that's a whole other can of worms).

I will concede that I failed to write a function definition, thanks for catching that. I guess I unintentionally refactored the outer function away because development brain took over? Sloppy on my part, regardless.

I would argue that extending "improved syntax" beyond readability to carry "addition of new features" blurs the lines between syntax and semantics.

The point was that modern JS is more convenient to use: Const/let, arrows, classes, proxies, async/await, generators, destructuring, default/rest/spread parameters, etc.

Even if you discard const/let/arrows as merely syntactic improvements (which they are not), you should not ignore the others - unless of course they are all syntactic improvements with added features at which point "syntax" lost its "meaning".

Reply on news.ycombinator.com