Hacker News Reader

Comment by seldo | Hacker News Reader

I would have thought this was obvious, but orders of magnitude more developers know Javascript than Lua[1], thanks largely to the popularity of browsers as a programming environment.

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

View on HN

Language popularity is a pretty fickle thing. It was not too long ago that you'd be laughed out of the room if you suggested using Javascript for any kind of serious work. Perl, once the king of scripting languages by orders of magnitude, is now viewed as being something close to COBOL: a few old guys know it, but none of the cool kids will touch it.

JavaScript has a uniquely privileged position, though. It is the only language you can use to script the browser. As long as that is the case (and browsers are a relevant programming environment), you will always have web developers who know it, either as their primary language or as a secondary one.

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.

The more things change, the more things change. Javascript isn't Perl and isn't being used like Perl. For example, people aren't turning it into an hardware embedded language.

> the three primary factors affecting the adoption of a programming language by developers are, in this order:

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

What makes the Arduino non-"bare"? The Arduino language is just C++, which gets compiled using gcc and uploaded using avrdude. It's not exactly running on a VM or using an interpreted language.

Sure, but with Arduino you're still floating on top of the Wiring libraries for almost anything you do. Coding a bare-metal AVR is a bit different:

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.

You can start with a straight-up Arduino program and mix in as much bare-metal AVR code as you like. There's nothing in between you and the hardware, and that's important when you discover that time matters.

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.

Thanks for sharing. I'm working (very slowly at the moment) on an AVR simulator in order to teach myself C. I think this is a great little program to compile and test with.

The Arduino library provides a lot more flexibility compared to the bare AVR + libc, but at the expense of performance. Notably using digitalWrite() can be up to 50x slower than writing to the port registers directly.

Yes, but you can still write to the port registers directly. Using the Arduino libraries doesn't lock you out of anything. There's a smooth, continuous path from high-level C++ abstractions built on the Arduino primitives down to the bit-twiddling low-level C world.

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.

I think JavaScript might be most successful on Arduino for the same reason - it's a platform with which most tinkerers are familiar.

http://blog.safaribooksonline.com/2013/07/16/javascript-powe...

I suspect Arduino (at least the ones I've used, Uno?) are a bit underpowered for higher level managed languages like JavaScript.

Absolutely. On AVRs, `new` and `malloc` work, but just barely. RAII/stack-only programming is basically a necessity. That is simply not possible with languages like Python or Javascript.

JS doesn't necessarily have to run natively for this kind of programming model to work out. Johnny5, the library discussed in the link I provided, rather provides an interface to the Arduino's StandardFirmata API http://firmata.org/wiki/Main_Pager

To be fair, the Espruino JavaScript interpreter manages this pretty well (in around 8kB of RAM). http://www.espruino.com

Anyone with a tinkerer's mind would not have a moment's trouble picking up Lua particularly if they already knew Javascript (or any other scripting language for that matter).

Also, of dynamic languages, JS is among the most performant, and many times faster than (say) Ruby.

Reply on news.ycombinator.com