Hacker News Reader

Comment by sklogic | Hacker News Reader

> 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?

View on HN

Because people know it. That's the only reason, but it's a huge reason.

...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.

> That's the only reason, but it's a huge reason.

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.

JavaScript is weird and stupid to begin with. Until it becomes the most widely used, fastest dynamically typed language.

Won't ever be "fastest" in embedded, no way you can run your v8 on such devices.

> Won't ever be "fastest" in embedded, no way you can run your v8 on such devices.

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/

Web assembly, as well as asm.js, is never meant to be manually written. It's a target for compilers. And even the most efficient ever implementation of web assembly won't make your plain old javascript any faster.

Examples? I gave a hat-tip to Lua and suggested why JS wins in this case (same argument for langs like Nim). Ruby and Python are too slow (currently). Go and Rust are fast but relatively low-level, tough-going for newbies.

Both Lua and JS are dynamically typed, which is not a very good idea for the low power, limited resources devices. There is a number of relatively high level, statically typed, compilable languages: Ada, Oberon, even the good old Pascal would be ok for the beginners. Not ideal, but at least much better than JS.

In practice with Lua, being dynamically typed isn't really the metric we're concerned about for power consumption. Typically Lua is used as a scripting interface to native APIs and hardware (via C). This is where most of your power consumption is going to live. Powering up a wi-fi antenna? That's going to cost way more than anything you can measure in Lua. Writing a video game? Your GPU is consuming most of the power.

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

Of course interpreter always eats up more cycles (so, more power) than a native code. Does not affect much peak consumption, but drains battery integrally.

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.

Ada is a good language for many things, but isn't very easy to use. It failed that test versus C.

Lua on the other hand, won that test plenty of times.

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.

> 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....

EDIT: Added the TIOBE link referenced.

So, in your using TIOBE as a baseline, are you suggesting that Java should be the language of choice for embedded platforms?

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...

> Java

You'd be surprised - see JavaCard.

> So, in your using TIOBE as a baseline, are you suggesting that Java should be the language of choice for embedded platforms?

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.

By this definition, their "Ratings" are not based on LoC.

> 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...

3 - https://en.wikipedia.org/wiki/Straw_man

I was actually referring to a web based user interface...

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).

Because millions of web developers know it, and if you make IOT type products you'd like to peel off a few of those people to work on your emerging platform.

Who need "developers" of this kind, who are unwilling to learn something as small as a language? And they won't be able to transfer any other knowledge from their realm of web browsers into embedded, besides this thin language layer. So, what's the point, again? I cannot see a single rational reason.

That's a very important point. As an unexperienced developer, you can learn C in a few weeks. Then spend another few weeks on learning how to write clean, maintainable code. I wouldn't want to work with people who don't even want to do that. You already named the most appropriate tools (Assembler, C, C++, and Forth), and learning at least one of them is very easy.

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.

Reply on news.ycombinator.com