On: JavaScript for Microcontrollers

[ehvatum]

A few years ago, I was astounded to find that I can write modern C++ code for arduino. It’s pretty great; rvalue && parameters, classes, even STL string manipulation all works perfectly. C++11 and later added all kinds of useful syntax for writing fast, small code. In particular, I don’t need nearly as much preprocessor macro crap, because it’s easy to make the compiler compute constants, even when those constants are produced by manipulating STL data structures.

Compiling expressive syntax through a powerful optimizing compiler to produce binaries run by microcontrollers is really sweet. Definitely the way to go, if you want to get the most functionality from limited hardware, without going all the way to assembly.

I guess JavaScript could be good for people who want to do very simple things, and then invest lots of time fighting limitations as their ambitions grow, rather than learning something useful. Like people do with Excel.

Which brings me to my next question: why not take it to the limit, and make microcontrollers programmable purely in Excel macros? That would be maximally accessible. Lots of people know Excel and can’t get enough pain.

[pjmlp → ehvatum]

Many forget that modern microcontrollers are much more powerfull than 16 bit home computers, and that is where I started with C++, had C, Turbo Pascal, Turbo Basic, QuickBasic, Clipper, Lisp, Prolog, Forth,.... at my disposal as well.

Sometimes reading comments about what microcontrollers aren't able to do in 2020 looks like cargo cult of people lacking the experience of how it was like to code with 640 KB.

[pojntfx → ehvatum]

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.

[_xrjp → ehvatum]

> Compiling expressive syntax through a powerful optimizing compiler to produce binaries run by microcontrollers is really sweet. Definitely the way to go, if you want to get the most functionality from limited hardware, without going all the way to assembly.

I highlight that. In fact, Rust is another kid on the block that is very promising for embedding.

In the other hand, sorry but I simply don't get why JS for interactions on such highly constrained devices. Probably as you said, it's intended to do very simple things with less effort as possible.

[LarvaFX → ehvatum]

Your sour attitude feels displeasing to read.