I'm struggling to understand - what's the point of using JavaScript for anything embedded?
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.
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.
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...
You'd be surprised - see JavaCard.
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).
The point, I would suspect, is lots of people already know JavaScript, so it lowers the barrier to entry to embedded programming.
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.
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.)
Indisputably. Lowering a barrier to entry isn't the same thing as guaranteeing success for every entrant.
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.