Earlier quoted context omitted.
Duktape website: "Embeddable, portable, compact: can run on platforms with 192kB flash and 64kB system RAM"
Also http://www.esp32.com/viewtopic.php?t=497
mJS – A new approach to embedded scripting
51–60 of 61 posts
Re: mJS – A new approach to embedded scripting
#5225k of flash space sounds like a lot for what is effectively just a JavaScript parser and interpreter. I recall the days when you could fit a whole language's compiler into a few measly KB. 1KB RAM is also quite a lot for certain boards, especially if it has to be stack or SRAM. How's the performance? Will my 72MHz Cortex or 16MHz Arduino be able to run interesting things with mJS? If I have to do everything through…
Re: mJS – A new approach to embedded scripting
#53Earlier quoted context omitted.
> none of the popular scripting languages have been designed for the embedded environment in the first place Also false for Lua. It is designed to be embedded.
Embedded environment in this context means hardware low on resources, e.g. microcontrollers. Your perception of that word is "embedded into the C/C++ program". These are two different things. I agree that Lua (like some other languages) were designed to be embedded into C/C++ apps.
Re: mJS – A new approach to embedded scripting
#54Earlier quoted context omitted.
Agreed that on-a-whole JS is not appropriate for embedded devices. However allowing scripting may be useful in particular pieces of the code, to allow easy extension / customization.
I recall that very much the same opinions were expressed about the JS and backend programming, until node.js appeared. Now the reality is different. To be honest, we do not think that JS is a good language for embedded. Like any other existing popular scripting language. Perhaps scripted Go would be a better choice. The point is that in many, many cases scripting brings a lot of benefits to the embedded environment.…
Re: mJS – A new approach to embedded scripting
#55Why is there so much stigma against _learning_ to code in something other than $favlang these days? Most hard core developers I know appreciate the importance of using the right tool for the job, I don't see embedded/desktop developers shying away from using whatever the native toolkit/language is for their chosen platform and instead shoehorning $x to fit as much as we see this constant trend to try to use "web tech" everywhere. (Scripting in embedded systems has long been a solved problem: use lua.)
Re: mJS – A new approach to embedded scripting
#56So is the only benefit of wasting that space and CPU so you can bill your platform/project/whatever as being "js" and C/C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support? Why is there so much stigma against _learning_ to code in something oth…
mJS might also be an option. I don't really see what's wrong with that if we have the space for it.
This can probably get types from Flow, since it is valid es6. Flow has no compilation step or runtime component.
You may have a point about the debugging, but JS is pretty easy to debug by printing to stdout.
Re: mJS – A new approach to embedded scripting
#57So is the only benefit of wasting that space and CPU so you can bill your platform/project/whatever as being "js" and C/C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support? Why is there so much stigma against _learning_ to code in something oth…
I'd say it's better to know one language and know it well.
Re: mJS – A new approach to embedded scripting
#58Earlier quoted context omitted.
None of which are particularly appropriate for embedded programming.
I've adopted a rule where I try to replace a sentence, thought, or expression with, "That's different from how we do things right now," and then try to see if it changes the meaning of what was actually said. Mostly, this is useful when the comment serves to justify shooting down another idea. "We can't do things that way, because we do things a different way", is something that many people will automatically recogni…
Re: mJS – A new approach to embedded scripting
#59Espruino's had an FFI interface for the last 3 years! Nice to see they did their research :)
Hi Gordon! Nice to meet you :) I am the author of the article, and I am quite fond of Espruino, it's a great project. Wasn't aware that Espruino has FFI API!
Re: mJS – A new approach to embedded scripting
#60So is the only benefit of wasting that space and CPU so you can bill your platform/project/whatever as being "js" and C/C++-free? What does a no standard library JS buy you over a no standard library C++11 everyone else is using these days, besides the pain and trouble of dealing with a dynamically typed language without native debugging support? Why is there so much stigma against _learning_ to code in something oth…
For example, I'm working on a dashboard for wifi routers that displays information beyond what is provided by OpenWRT's ubus system. We're get this information from the kernel, but it needs to be converted to JSON to be consumed by the dashboard frontend. Right now, I'm converting the information to JSON using Go, but there are some platforms that Go can have problems compiling binaries for. We have also written a lo…
Not to mention Lua itself can be used as a data / configuration language, their tables syntax is made especially for that. Normally when I work with Lua I don't feel the need to embed any other parsers for configuration, but cjson is there if you want.