5 ms·

I'm struggling to understand - what's the point of using JavaScript for anything embedded?

by sklogic 11y ago

dragonwriter 11y ago
> I'm struggling to understand - what's the point of using JavaScript for anything embedded? The point, I would suspect, is lots of people already know JavaScript, so it lowers the barrier to entry to embedded programming.
- sklogic 11y ago
  Language is the least important barrier to entry to any field. Domain knowledge is much more important.
  - dragonwriter 11y ago
    Domain knowledge of the type relevant to programmers in many fields is gained through experience programming in that field, not non-programming experience in that field. 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.
    - AdieuToLogic 11y ago
      The problem in this particular case is that the concerns of embedded systems are orthogonal to what anyone who knows _only_ JavaScript has ever dealt with. Those worlds are simply too far apart. 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.
  - nostrademons 11y ago
    Depends on the age of the field. When fields are young, nobody has any domain knowledge anyway, because the "domain" just got started. At this point, things like technical knowledge, familiar programming languages, and common data protocols are crucial, because that's all the knowledge that exists. 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.
    - sklogic 11y ago
      This particular field is ages old, with tons of accumulated domain lore.
- userbinator 11y ago
  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.)
  - dragonwriter 11y ago
    > 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 Indisputably. Lowering a barrier to entry isn't the same thing as guaranteeing success for every entrant.
  - dottrap 11y ago
    Be careful not to conflate web programming with plain-old JavaScript the language. A lot of the horrible bugs in web programming come from the massive complexity and size related to web browsers, the DOM, and over-engineered frameworks. 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.
nilliams 11y ago
Because 'scripting' hardware (coding in a fairly high-level language) is a lot of fun and coding the same sorts of things in C is pretty painful & requires up-front knowledge of a lot of stuff you don't really need to know til later (memory management, types etc). Sure there's Lua et al but JS is just a more relevant language nowadays.
- sklogic 11y ago
  > coding in a fairly high-level language 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?
  - tracker1 11y ago
    JavaScript is arguably the most broadly written and utilized language by programmers... that makes it well suited to any environment that it can be used in. It may not be the best option for any given environment, but that is besides the point. 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.
    - AdieuToLogic 11y ago
      > JavaScript is arguably the most broadly written and utilized language by programmers... that makes it well suited to any environment that it can be used in. 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.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... EDIT: Added the TIOBE link referenced.

I'm struggling to understand - what's the point of using JavaScript for anything embedded?

by sklogic 11y ago

I'm struggling to understand - what's the point of using JavaScript for anything embedded?

> I'm struggling to understand - what's the point of using JavaScript for anything embedded? The point, I would suspect, is lots of people already know JavaScript, so it lowers the barrier to entry to embedded programming.

sklogic 11y ago
Language is the least important barrier to entry to any field. Domain knowledge is much more important.
- dragonwriter 11y ago
  Domain knowledge of the type relevant to programmers in many fields is gained through experience programming in that field, not non-programming experience in that field. 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.
  - AdieuToLogic 11y ago
    The problem in this particular case is that the concerns of embedded systems are orthogonal to what anyone who knows _only_ JavaScript has ever dealt with. Those worlds are simply too far apart. 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.
- nostrademons 11y ago
  Depends on the age of the field. When fields are young, nobody has any domain knowledge anyway, because the "domain" just got started. At this point, things like technical knowledge, familiar programming languages, and common data protocols are crucial, because that's all the knowledge that exists. 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.
  - sklogic 11y ago
    This particular field is ages old, with tons of accumulated domain lore.
userbinator 11y ago
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.)
- dragonwriter 11y ago
  > 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 Indisputably. Lowering a barrier to entry isn't the same thing as guaranteeing success for every entrant.
- dottrap 11y ago
  Be careful not to conflate web programming with plain-old JavaScript the language. A lot of the horrible bugs in web programming come from the massive complexity and size related to web browsers, the DOM, and over-engineered frameworks. 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.

nilliams 11y ago

Because 'scripting' hardware (coding in a fairly high-level language) is a lot of fun and coding the same sorts of things in C is pretty painful & requires up-front knowledge of a lot of stuff you don't really need to know til later (memory management, types etc). Sure there's Lua et al but JS is just a more relevant language nowadays.

sklogic 11y ago
> coding in a fairly high-level language 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?
- tracker1 11y ago
  JavaScript is arguably the most broadly written and utilized language by programmers... that makes it well suited to any environment that it can be used in. It may not be the best option for any given environment, but that is besides the point. 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.
  - AdieuToLogic 11y ago
    > JavaScript is arguably the most broadly written and utilized language by programmers... that makes it well suited to any environment that it can be used in. 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.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... EDIT: Added the TIOBE link referenced.