I don't have much problem with programming an embedded device in a high-level language, but why JS specifically? Why not Lua, which just as fast, and is better than javascript in many respects?
According to some recent research[2], the three primary factors affecting the adoption of a programming language by developers are, in this order:
1. Libraries available
2. Familiarity
3. Performance
And per the paper, this order of preference is extremely strong. Which means, because of the huge mass of Javascript developers out there, that as soon as a library becomes available to do something in Javascript, Javascript will rapidly become the most popular way to do that thing, regardless of the performance hit.
[1] http://redmonk.com/sogrady/2012/09/12/language-rankings-9-12... [2] http://www.eecs.berkeley.edu/~lmeyerov/projects/socioplt/pap...
http://blog.safaribooksonline.com/2013/07/16/javascript-powe...
> 1. Libraries available
Not just programming languages. Microcontrollers too. You could get much better performance out of a bare AVR, but where are the libraries and modules? Whereas an Arduino comes with a library for anything that moves - of course most people are going to prefer it.
http://florin.myip.org/blog/how-make-halloween-creepy-blinki...
There's no significant difference, unless you want fully predictable real-time behavior (of which my piece of code is NOT an example, but that's all I have online).
Most people shouldn't care.
I've done a fair amount of embedded work, some with AVRs and some with various ARM chips, mostly Cortex-M3... I always start with the nice libraries because why waste your time reinventing that stuff if you don't have to? But when you have to reach deeper and gain finer-grained control over your hardware - and almost every project eventually has to do that eventually - it's really, really nice not to have some VM in the way, not to have to start over in a lower-level environment.
If you're walled off in a Javascript VM, you can never have that kind of transparent access to the hardware - which seems like a big problem when you are building electronics, and controlling the hardware is the entire point of the job.
Imagine if the only way you could script Linux servers was in Perl -- it's hard to imagine it falling off in popularity the way it did in our universe. Other languages supplanted it because other languages could supplant it.
And even more off topic (sorry), what makes Lua better/different than other scripting languages?
EDIT: On jacobwcarlson suggestion, I Googled Lua vs Python, and found this Wiki, http://lua-users.org/wiki/LuaVersusPython Not a speed comparison, but gives a fair amount of difference in the actual languages. And yes it is on a Lua users site, so may be biased, but on my very light reading didn't seem too bad.
Although I'm one of those Lua "unadopters", for me it's better to simplify stuff to my audience, and I have considered seriously to use JavaScript for my next project instead of Lua.
So they each have their trade offs.
Lua doesn't have to be backwards compatible because nobody has to upgrade to the latest version of lua- and there isn't much of a standard library to break anyway- All the things you'd traditionally use a library for are provided by the outer application lua is embedded in- an application likely not written in lua itself- and so if you do decide to upgrade your app/game the only thing you break is individual scripts.
Whenever you release a new version with backwards-incompatible changes you discourage your audience to update and they fragment.
Your product exist because it solves a problem, and the moment your product gives more problems than the ones it solves, you discourage your users to use your product and they begin to look for options, and if an option that meets their needs doesn't exist they will stall (ex. Windows XP).
This means extra effort, since you have to maintain at least the most used major versions, and at the very least provide security updates to your users. Fragmentation is a <s>headache</s> migraine that you want to avoid whenever it's possible...
With a widespread adoption you have to evaluate deeply whether the fragmentation troubles are worth the value the backwards-incompatible changes will provide. It's not the same trouble having a hundred users, than having a billion users.
But suddenly the project becomes a product, and the product gets adoption (every time more).
The users will use your product because of different reasons (ex. it's what other people use / it's what can solve better X problem / it's what I got recommended / etc.), the users that like and feel identified with the project become a small niche in comparison with the people that need the product.
The users become the ones that shape the product, you have to balance between:
Feature A. Which is what you want to do for the project. Feature B. Which people are telling you they need for the product.
Will you develop exclusively "Feature A"s, because you are following a philosophy?
Think for a moment what would had happened if Microsoft had adopted Lua for IE3 instead of reverse engineering Netscape's JavaScript (assuming that IE would have still won the 90's Browser Wars thanks to Lua). Are there flying cars in that parallel universe? Is Lua uglier than today's JavaScript? Has Douglas Crockford written Lua: The Good Parts yet? :)
But one area where Lua is gaining traction is because it is the only high level language that is integrated with Nginx.
Running your own code inside your front-facing web host was bad when Apache brought in mod_php and is bad now.
Its only real drawback is a lack of libraries/package manager compared to, say, Python/Ruby (respectively). I guess some people might miss built-in support for classes.