8 ms·
Why?
by stathibus 5y ago
Why?
- laurent123456 5y ago> 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 agoRight, but why would anyone want to do that? Who thinks that JavaScript is a good choice for this?
- umvi 5y agoWhy is JavaScript a bad choice for this?
- wyager 5y agoMany 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 agoThat's just like your opinion man. It would be my first choice.
- tyingq 5y agoI imagine it's nice for things like a product that allows some amount of scripted control by end users.
- kennywinker 5y agoPeople who know javascript
- edoceo 5y agoAnd can now run in a tiny engine!
- pjmlp 5y agoPeople 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 agoOk that's an argument for other languages, but not for JavaScript. JS is not good.
- _448 5y agoJust 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 agoLook up how many Js basics tutorials there are, then check how many Pike basics tutorials there are
- jlund-molfese 5y agoPrototyping and hobby use are the two obvious use cases I can think of.
- bArray 5y agoI can imagine this would be great if you want to have multiple tiny apps running on a small embedded device - even with some basic multi-tasking! This is actually super cool. Literally just yesterday I was trying to find the equivalent for Java, byte code or otherwise. I want to attempt to run several nano JVM apps on an ESP32, but I'm starting to think that it might not be possible. Many years ago now I ran a custom 'script runner' that fit into 512 bytes of assembly language for a custom kernel (that was also 512 bytes) [1]. I would really like to play with something like Elk and see what can be done! [1] https://bitbucket.org/danielbarry/saxoperatingsystem/src/master/PROGRAMS/RUN/RUN.ASM https://bitbucket.org/danielbarry/saxoperatingsystem/src/mas...
- wyager 5y agoIt seems to me that embedded Lua would be a more appropriate choice, and barring that, there is already a quite robust embedded Python implementation. Don't get me wrong, this is a cool project, but I don't see why you would ever choose to use JS in an embedded context except for fun. The arguments for using lua or micropython are already very narrowly applicable.
- afavour 5y agoSeems inarguable to me that JavaScript is much more widely known and adopted than Lua. So it makes sense to use JS in 'toy' like environments where someone is learning an embedded platform.
- CameronNemo 5y agoJS is more common, but this is not a complete implementation. So those skills may not transfer 100%.
- saagarjha 5y agoBut they certainly will more than they would to a completely new language…
- 5y ago
- deleted 5y ago[deleted]
- edoceo 5y ago> Anything that good hackers would find interesting. Totally on topic. I dislike JS but this is rad. And like upthread said, clean understandable implementation. Very educational.
- bsder 5y agoBecause "20KB on flash/disk, about 100 bytes RAM" is smaller than practically anything out there in the space. Forth is at that size. Tcl implementations are at least triple that. As are all the Schemes I have seen. Lua similarly. Anything I've missed?
- seabird 5y agoBecause your system may require that you can change code at runtime without reflashing your micro. I very, very much dislike JavaScript, but it's not an outlandish requirement and there's not a lot of (what I would consider) great options in that arena with expansive C interop (which you would need for a "real" application). There's basically JavaScript, Python, and Lua. There's plenty of other stuff out there, but none with the same amount of backing as those three. Embedded development is the bat country of software. You will definitely have to do some unsavory things to get where you're trying to go.
- hatch_q 5y agoWouldn't there be better options for that? python, lua, tcl, perl, ... ?