5 ms·

> Instead of writing firmware code in C/C++, Elk allows to develop in JavaScript. Another use case is providing customers with a secure, protected scripting env

> Instead of writing firmware code in C/C++, Elk allows to develop in JavaScript. Another use case is providing customers with a secure, protected scripting environment for product customisation.

stathibus 5y ago
Right, but why would anyone want to do that? Who thinks that JavaScript is a good choice for this?
- umvi 5y ago
  Why is JavaScript a bad choice for this?
  - wyager 5y ago
    Many reasons occur to me, but the top few would be: * Lua already exists and is better suited to this * JS is a relatively complicated language to evaluate * JS requires a large amount of dynamic allocation * JS isn't really the first thing (or in the top 25 things) I would pick when developing on a platform where I wasn't already stuck with it
    - kennywinker 5y ago
      - JS requires a large amount of dynamic allocation One of the top listed features of this interpreter is a fixed memory footprint - JS is a relatively complicated language to evaluate In developing this interpreter they eliminated some of the languages features to make it simpler.
      - q-rews 5y ago
        > In developing this interpreter they eliminated some of the languages features to make it simpler. That means you can't run general-purpose code safely, which means you should probably write/rewrite/adapt it, which means you might as well use a different language. I'm a JS developer, but the parent might have a point here. Why run something like this in production when you're likely to end up in unexpected situations? Either a runtime is compliant, or you're going to have a bad time. The project is cool, but I wouldn't use it as an example for what JS can do.
      - raxxorrax 5y ago
        > One of the top listed features of this interpreter is a fixed memory footprint In embedded systems that is often a necessity but calling it a feature instead of a constraint is a good idea.
    - thisismyaccpunt 5y ago
      That's just like your opinion man. It would be my first choice.
- tyingq 5y ago
  I imagine it's nice for things like a product that allows some amount of scripted control by end users.
- kennywinker 5y ago
  People who know javascript
  - edoceo 5y ago
    And can now run in a tiny engine!
- pjmlp 5y ago
  People that grew up with BASIC, z80 and 6502 Assembly and know C isn't the answer for everything. The example with ESP32 is quite, the hardware is much more powerful than pre-Windows PCs, so why pretend it is something where C and Assembly are the only answer, when MS-DOS had plenty of languages to chose from.
  - stathibus 5y ago
    Ok that's an argument for other languages, but not for JavaScript. JS is not good.
_448 5y ago
Just out of curiousity, how is Pike[0] for this type of use-case? [0] https://pike.lysator.liu.se/development/git/ https://pike.lysator.liu.se/development/git/
- BoorishBears 5y ago
  Look up how many Js basics tutorials there are, then check how many Pike basics tutorials there are

> Instead of writing firmware code in C/C++, Elk allows to develop in JavaScript. Another use case is providing customers with a secure, protected scripting environment for product customisation.

stathibus 5y ago

Right, but why would anyone want to do that? Who thinks that JavaScript is a good choice for this?

umvi 5y ago
Why is JavaScript a bad choice for this?
- wyager 5y ago
  Many reasons occur to me, but the top few would be: * Lua already exists and is better suited to this * JS is a relatively complicated language to evaluate * JS requires a large amount of dynamic allocation * JS isn't really the first thing (or in the top 25 things) I would pick when developing on a platform where I wasn't already stuck with it
  - kennywinker 5y ago
    - JS requires a large amount of dynamic allocation One of the top listed features of this interpreter is a fixed memory footprint - JS is a relatively complicated language to evaluate In developing this interpreter they eliminated some of the languages features to make it simpler.
    - q-rews 5y ago
      > In developing this interpreter they eliminated some of the languages features to make it simpler. That means you can't run general-purpose code safely, which means you should probably write/rewrite/adapt it, which means you might as well use a different language. I'm a JS developer, but the parent might have a point here. Why run something like this in production when you're likely to end up in unexpected situations? Either a runtime is compliant, or you're going to have a bad time. The project is cool, but I wouldn't use it as an example for what JS can do.
    - raxxorrax 5y ago
      > One of the top listed features of this interpreter is a fixed memory footprint In embedded systems that is often a necessity but calling it a feature instead of a constraint is a good idea.
  - thisismyaccpunt 5y ago
    That's just like your opinion man. It would be my first choice.
tyingq 5y ago
I imagine it's nice for things like a product that allows some amount of scripted control by end users.
kennywinker 5y ago
People who know javascript
- edoceo 5y ago
  And can now run in a tiny engine!
pjmlp 5y ago
People that grew up with BASIC, z80 and 6502 Assembly and know C isn't the answer for everything. The example with ESP32 is quite, the hardware is much more powerful than pre-Windows PCs, so why pretend it is something where C and Assembly are the only answer, when MS-DOS had plenty of languages to chose from.
- stathibus 5y ago
  Ok that's an argument for other languages, but not for JavaScript. JS is not good.

_448 5y ago

Just out of curiousity, how is Pike[0] for this type of use-case? [0] https://pike.lysator.liu.se/development/git/ https://pike.lysator.liu.se/development/git/

BoorishBears 5y ago
Look up how many Js basics tutorials there are, then check how many Pike basics tutorials there are