Live data from Hacker News

JavaScript right on the hardware

technical.io

71–80 of 320 posts

Re: JavaScript right on the hardware

#71
post #54
post #28

First off, this is cool. It is tremendously exciting to see the bar for hardware hacking getting lower and lower. To the people complaining "Why JS? C is fine!", remember that once the complaint was "Why C? ASM is fine!". At the same time, I can't help but grin that we on the CS side find a way to erase all the gains in performance and efficiency as soon as the EE guys make them. There has to be come kind of universa…

I don't have much problem with programming an embedded device in a high-level language, but why JS specifically? Why not Lua, which just as fast, and is better than javascript in many respects?

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

Re: JavaScript right on the hardware

#72
post #51

Earlier quoted context omitted.

When all you know how to use is a hammer, everything looks like a nail...

"True. When your hammer is C++, everything begins to look like a thumb." [1] [1] http://www.anvari.org/fortune/Quotations_-_Random/3041_quote...

Why it's always C/C++ (not even Pascal or Oberon) in another corner of the ring? If hardware is powerful enough to sustain Node.JS, why not use OCaml, Racket or, maybe, some JVM-based language? Or, if the scripting is a requirement, Lua, Tcl or maybe Python.

Re: JavaScript right on the hardware

#73
post #36
post #24

Earlier quoted context omitted.

You prefer C over JavaScript? Header files? Pointer arithmetic hell? Precompiler Macros? Manual Memory Management? Seriously? To each their own, though.

No. I prefer C over JavaScript for embedded devices. And actually in most places, too. I know I'm weird, but I really like pointers, because I really like being able to manually setup data structures, and enjoy the power provided by pointers. Manual memory management isn't horribly fun, but for embedded devices I would rather be in charge of that over the chip having to do it for me. It means that if there's ever a m…

Sure if you write very low level stuff, C is probably more suitable. I wonder how much today's "embedded devices" still have in common with traditional embedded devices, though? If it is capable of running JavaScript, it probably is a lot more powerful than some microprocessor with just 2KB RAM where you have to squeeze every bit out of your code. On the PI you can run a complete Linux installation. I don't think these devices are actually embedded, they are just smaller than "normal" computers.

Re: JavaScript right on the hardware

#74
post #49
post #28

First off, this is cool. It is tremendously exciting to see the bar for hardware hacking getting lower and lower. To the people complaining "Why JS? C is fine!", remember that once the complaint was "Why C? ASM is fine!". At the same time, I can't help but grin that we on the CS side find a way to erase all the gains in performance and efficiency as soon as the EE guys make them. There has to be come kind of universa…

I don't think the language has been the problem. Just look at the Arduino. For me, the main challenges always were getting the program onto a chip and wiring everthing so that is does not break or shortcut.

Errrrm, if you ever look at the AVR C library that Arduino was based off of, you would probably not be so quick to say that it isn't a language issue. Not having to know the weird unpronounceable mnemonic for a certain register as well as the specific bit in that register that you set in order to trigger the ADC is a huge plus. Greater abstraction is always welcome if the hardware can handle it.

Although I agree with you that Arduino C is simple enough for most microcontroller programs and Javascript is a bit overkill.

Re: JavaScript right on the hardware

#75
post #66
post #50

Earlier quoted context omitted.

It's extremely simple - basically everything is a hash. It has full lambda, not just crippled lambda like Python. It's very fast (I think it is the fastest scripting language except for Lua, and getting faster because of the browser wars). It usually doesn't require a lot of boilerplate code. What is not to like? The one thing I worry about is the limited range of integers.

I personally don't like that everything's a hash. It's nifty, and it means you don't really need objects, but I kinda like objects, even if I don't use them frequently in Python. Your preference makes sense, it's just not the same one I have. More on topic for this thread, I'm still not convinced that it's a good thing for an embedded system.

You can use objects in JS if you want to - but fair enough, different tastes and preferences.

Re: JavaScript right on the hardware

#76
post #28

First off, this is cool. It is tremendously exciting to see the bar for hardware hacking getting lower and lower. To the people complaining "Why JS? C is fine!", remember that once the complaint was "Why C? ASM is fine!". At the same time, I can't help but grin that we on the CS side find a way to erase all the gains in performance and efficiency as soon as the EE guys make them. There has to be come kind of universa…

http://en.wikipedia.org/wiki/Wirth's_law

Re: JavaScript right on the hardware

#77
post #71
post #54

Earlier quoted context omitted.

I don't have much problem with programming an embedded device in a high-level language, but why JS specifically? Why not Lua, which just as fast, and is better than javascript in many respects?

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 pref…

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

Re: JavaScript right on the hardware

#78
post #68
post #60

Earlier quoted context omitted.

@eob - same problem, couldn't reply directly to you. My main reason for liking Python isn't that it's compact and manageable (unless by compact, you mean the code one writes), but because I like the elegance of the language. You're saying you have to stick to strict conventions for JavaScript to be any good? That would imply that it isn't any good to me. I use it, frequently, I just prefer not using it.

I think JS is more elegant than Python - just different tastes, I suppose. I find the crippled lambda unacceptable, and I don't like things like len() as a standalone function (in Python).

Yeah that len thing's weird, I probably had similar thoughts when I started using Python, but got over it.

I don't use lambdas, so that doesn't carry into how I compare languages.

Re: JavaScript right on the hardware

#79

This is very cool, but I don't see how it can compete with boards like the BeagleBone Black. The BleagleBone Black is $45 for a 1GHz CPU and 512 MB of memory, yet the access to low-level hardware is just as good.

Looks like the JavaScript bindings for Tessel are better. Comparing the demo for blinking an LED: var b = require('bonescript'); var state = 0; b.pinMode("USR3", 'out'); setInterval(function() { state = state ? 0 : 1; b.digitalWrite("USR3", state); }, 100); vs var tessel = require('tessel') tessel.led(1).blink() If they can give human-friendly names to stuff like "USR3" and "P9_40" and "P9_36" out of the box, then I'…

But that's a library issue, not a hardware issue. It shouldn't be difficult to write a wrapper for bonescript that turns the first example into the second example.

Re: JavaScript right on the hardware

#80
post #51

Earlier quoted context omitted.

"True. When your hammer is C++, everything begins to look like a thumb." [1] [1] http://www.anvari.org/fortune/Quotations_-_Random/3041_quote...

Why it's always C/C++ (not even Pascal or Oberon) in another corner of the ring? If hardware is powerful enough to sustain Node.JS, why not use OCaml, Racket or, maybe, some JVM-based language? Or, if the scripting is a requirement, Lua, Tcl or maybe Python.

Because a lot of people know Javascript and C/C++.
Post reply on HN