On: JavaScript for Microcontrollers

[pojntfx]

You probably haven't written modern JS. Since ~2016 (ES6) the language is basically completely different and really concise now; consider ES5:

  function increment() {
    var out = []

    for (let i of [1,2,3,4,5]) {
      out.push(i + 1)
    }

    return out
  }

vs ES6:

  const increment = () => [1,2,3,4,5].map(i => i + 1)

etc. Most people's experience with JS/TS has simply been before ES6 (which had massive problems, like `var` and `this` scoping etc.), it's really nice nowadays.

[chaorace → pojntfx]

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.

[frankenst1 → chaorace]

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]

[chaorace → frankenst1]

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.

[frankenst1 → chaorace]

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".

[fallenatreus → frankenst1]

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

[frankenst1 → fallenatreus]

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]

[eitland → pojntfx]

The problem with JS and large applications was never the verbosity but that you can do horribly mistakes without getting any feedback until runtime since your mistakes are valid JS, they just mean something else than what you meant.

I.e. due to the lack of typing this will fly just fine:

const calculateInterestingNumber = () <calculations goes here>;

let twiceAsInterestingNumber = 2 * calculateInterestingNumber; // (ooops, missing parenthesis)

... until runtime.

This was just the silliest contrived example.

In practice this - as you are fixing someone else's code and misplace/forget a set of parenthesis - ends up taking 30 minutes to figure out.

[path411 → eitland]

Use typescript then

[eitland → path411]

That's exactly what we do.