JerryScript – A JavaScript Engine for Internet of Things
samsung.github.io
samsung.github.io
It looks very constrained in what it supports so far though.
Update: They're at ECMAScript 5.1 https://github.com/Samsung/jerryscript/issues/205 but not all tests are running https://github.com/Samsung/jerryscript/issues/158
Ok, it doesn't yet JSON.stringify https://github.com/Samsung/jerryscript/issues/432 so not sure if ready yet.
- http://duktape.org/
- http://mujs.com/
- https://github.com/gfwilliams/tiny-js
- http://pdqi.com/cgi-bin/cgiwrap/pdqi/jsi.cgi/doc/tip/jsi/www/index.wiki
- https://github.com/PaulBernier/castl
- https://github.com/tessel/colony-luaOpinion: Lua is a better choice for IoT but alas the programming "market" has (again) chosen the worse alternative.
In addition, the point of having Javascript is so that I can get my junior software folks (proxy for any inexperienced programmer) to write things for my embedded hardware instead of having to haul out my senior staff engineers who have 20 years of experience writing C for embedded devices.
Look at Arduino vs. Raspberry Pi/BeagleBone. Arduino has way more developers because it was orders of magnitude easier to program. Ecosystem is important.
Why is being 0-based more important on embedded compared to other contexts?
You have slipped up.
Sure there's Lua et al but JS is just a more relevant language nowadays.
JavaScript is not that high-level anyway, and there are many high-level languages that are much more embedded- and realtime-friendly. Why choosing JavaScript over the much more suitable ones?
...though I'm not sure what languages you think are more high-level that are not thereby made somewhat more difficult to use by beginners and/or on small projects, which would rather defeat the purpose, since the actual code running on these cheap microcontrollers is usually relatively small.
Kinda stupid reason.
> more high-level that are not thereby made somewhat more difficult
Usually, the higher the level of the language, the easier it is to use. I would never call JS an easy language.
V8 won't always be required for fast Javascript. If Web Assembly[1] pans out as planned, I can foresee embedded devices that can execute wasm code natively (or at least fast)
1. https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
And Lua has proven itself in limited/constrained resource environments for over 20 years. In practice, it is really good in this space.
And a further interesting point about Lua somebody pointed out to me...now that most modern architectures are cache oriented and memory buses are often the bottleneck, it is amazing that Lua is small enough to fit in the L2 cache. Think about this...it is almost like having Lua in hardware on the chip.
Note: Canonical PUC-Rio Lua does not have JIT. You aren't burning all the cycles you think you are if you are applying typical arguments about the JVM or JavaScript JITs.
Edit: typo
Anyway, there is no point at all (zero, full stop) in using a dynamic language in embedded, where all your code is fixed and rarely updated, with no runtime metaprogramming (eval and such).
And, sorry, but there are far better uses for the L2 cache than keeping any fat interpreter there. I would have accepted a cache locality argument for a direct threaded code (and that's the reason why Forth rocks more than C in embedded), but not the Lua kind of interpreter.
Lua on the other hand, won that test plenty of times.
That argument is incorrect. According to TIOBE[1], JavaScript ranks as the 9th most popular programming language with a "Ratings" of %2.194. Behind Visual Basic.NET and PHP.
> It may not be the best option for any given environment, but that is besides the point.
No... that is the precise point "sklogic" is making.
> From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
By your own argument, then, the most sensible languages to choose from are those which have been used in embedded systems for decades. Assembler, C, sometimes C++, and Forth.
Or, ignoring people with embedded systems experience, put PHP on a chip and hire people who know it.
1 - http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
EDIT: Added the TIOBE link referenced.
From their home page: "It is important to note that the TIOBE index is not about ... the language in which most lines of code have been written."
MOST software development these days has a web component... not all, but most... that means JavaScript... I would posit that more developers have used JavaScript to some degree than any other language... not their only or primary language.
My argument was to the number of developers who know/use JS... not the language with the most deployed instances. Also, calling out JS for being bad, and suggesting PHP as a language to use is a pretty bad alternative... especially given that everyone who's written PHP has also, most likely written JS.
Node was developed precisely because JS makes a good domain language for interfacing with lower-level libraries. I can see the argument for Lua...
Many do by way of Java ME[1], though that would not be my first choice. As I said regarding your premise of a business case:
> > From a business perspective it makes a lot of sense to use languages that allow for as broad a hiring scope as possible with the least amount of cross/re-training.
> By your own argument, then, the most sensible languages to choose from are those which have been used in embedded systems for decades. Assembler, C, sometimes C++, and Forth.
The vast, vast, majority of embedded systems are written in one of the aforementioned four languages (with a nod to Java ME since I do not have metrics regarding its production use in embedded systems). There exists a huge software world outside of the browser.
> From their home page: "It is important to note that the TIOBE index is not about ... the language in which most lines of code have been written."
Reviewing my earlier comment revealed that I forgot to include the referenced link. It has been updated to help disambiguate that post.
From it, there is a definition[2] of the "Ratings" I quoted:
The ratings are calculated by counting hits of
the most popular search engines. The search query
that is used is
+"<language> programming"
The number of hits determines the ratings of a
language.
...
The ratings are calculated with the following formula:
((hits(PL,SE1)/hits(SE1) + ... + hits(PL,SEn)/hits(SEn))/n
where n is the number of search engines used.
> MOST software development these days has a web component... not all, but most... that means JavaScript...
Giving the largest room for expression, I'll interpret "a web component" as software having some form of networking capacity. With that caveat, sure, network communication is very prevalent.
However, assuming this implies JavaScript is a straw man argument[3]. Much network communication exists outside the browser as well.
> Node was developed precisely because JS makes a good domain language for interfacing with lower-level libraries.
I disagree with this, but respect your right to have that (and any other) opinion. In an attempt to keep from going completely off topic, I won't go into this anymore in this thread :-).
1 - http://www.oracle.com/technetwork/java/embedded/javame/index...
2 - http://www.tiobe.com/index.php/content/paperinfo/tpci/progra...
I did a couple of searches on indeed for phoenix, and san francisco, and JavaScript seems to outnumber C++ and C# by a bit, and be fewer than Java.
For interpreted languages, Python was similar in SF, but less in Phx... and ruby was less in both. And there's also the most popular languages on github (#1 being JS).
You'd be surprised - see JavaCard.
Pick the right tool for the right job. That's what I read all the time. The current approach of 'the industry' is porting JavaScript to just about everything, which is insane. But, you know, learning JavaScript is simple and that's what matters! Well, JavaScript isn't that simple. But writing insane, ugly code and making it run by accident is easier in JavaScript, for example, than in one of the more complex languages.
I've seen things. Things I couldn't imagine in many other (static) languages, because it wouldn't even compile. Things that let me ask 'how did you even get this job?' over and over again.
The point, I would suspect, is lots of people already know JavaScript, so it lowers the barrier to entry to embedded programming.
Embedded systems often have very different characteristics than e.g. a web app, and just because someone has been doing JS web apps does not mean they'll be any good at using JS with an embedded system (and vice-versa, but maybe less so.) IMHO lowering the barrier to entry is just going to result in many more buggy/insecure IoT devices... (JS does eliminate certain classes of bugs associated with traditional embedded languages like C, but there are plenty other bugs you can find in web apps that are not buffer overflows.)
If we're talking about streamlined, embeddable JavaScript, we're not bringing the web and all those bloated frameworks.
You are right that those writing web apps won't necessarily be good at embedded systems, especially since (for now), they will have to also separate web APIs from JS-the-language and will not have the APIs they are used to.
But those who survive the transition process will likely pick up better habits. I suspect the APIs and usage will end up looking a lot like the Lua sphere, though perhaps more fragmented since none of JavaScript engines have anything remotely resembling compatible C API interfaces.
Indisputably. Lowering a barrier to entry isn't the same thing as guaranteeing success for every entrant.
As a field ages and accumulates best practices and social patterns, domain knowledge becomes relatively more important and technology choices become relatively less important.
Many of the biggest profit opportunities in a field come from owning the platform it's built upon, which is why it's logical to try and attract developers early with technologies they're familiar with. Eventually domain knowledge will matter more - but that depends upon the platform becoming big enough that it's a domain.
Unfamiliar programming language is an impediment, for many, to that learning process. If the tradeoff for that is a much clearer mapping to the domain than a more familiar alternative, the unfamiliar language may be, pedagogically, a net win, but -- especially for self-study -- people are more likely to learn enough to look deeply into the domain (including through unfamiliar languages) if the initial entry path is easy from where they currently are.
Your case is entirely valid when, say, a person is hired to work in a retail system and who had previously worked in some form of a decision support system.
Here, just say "resource-constrained devices" or something with ANY amount of meaning.
It's extremely unpleasant to program something with just a few KB of RAM and not know exactly what memory goes where. However, a lot of IoT-related gadgets just gather a buffer of data from an ADC or something, average it and send it over some wireless protocol every 1 minute. The allocation pattern is predictable enough that you don't run into strange cornercases.
I see no reason why anyone would want to use this commercially, but for the enthusiast market (and maybe even for some rapid prototyping) this looks interesting enough.
Ardunino Uno (ATmega CPU): 2KB RAM, 32KB ROM - Too small.
Arduino DUE (ARM CPU): 96KB RAM, 512KB ROM - Yes.
Raspberry Pi (ARM CPU): 256MB RAM, 1GB+ ROM - Yes, but why?
So the target for JerryScript is machines in the Due range. Rust has been crammed into the Arduino Due, which may become a good approach for embedded work. Go probably won't fit; too much runtime.
They're all in the $25-$45 price range. The Due, surprisingly, is the most expensive.
To be fair, that system really doesn't run anything dynamic well.
However, your point stands. Requiring 64K of RAM puts this above most ARM Cortex M0 chips.
Picobit (https://github.com/stamourv/picobit) sits comfortably in 16K ROM/4K RAM. There's no good reason why Javascript vouldn't do the same.
It is a tiny chip with included wifi. It was 2 digital IO ports, and also a serial connection if you want to connect it to an arduino.
And at the moment it costs 2.6 USD on ebay!!!
And someone made a plugin so you can program it from the Arduino IDE: https://github.com/esp8266/Arduino
Power is a bit of a concern, and it all depends on the environment... being able to get every web monkey coding in more environments is a big win for enthusiasts and commercial applications for limited scope projects... Hell, without a screen or antenna powered on all the time, you can get a lot of processing done on even a smart phone from two generations ago.
This has been around for a lot longer than Samsung's (as far as I know) and has a lot of great support. If you're looking for a small, embedded JS processor built specifically for this kind of thing, I'd recommend Espruino.
[1] http://english.stackexchange.com/questions/132868/jury-rigge...
But I just hate this "Internet of Things" name... There must be a better suited name for it.