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 universal constant: the limit, as technology proceeds into the future, of the execution time of "Hello World" is some fixed number. Because as soon as we get better hardware, we invent an even weightier runtime environment to slap on it. ;)
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.
This is a long-noted phenomena. The old saying that summed it up was, "Andy giveth, Bill taketh away." (Referring to Andy Grove of Intel and Bill Gates of Microsoft.)
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.
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.
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).
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.
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
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).
Slightly off topic, but is it just me or has Lua gotten a lot of attention on HN in the past weekish? I haven't heard much of Lua before but recently it seems to have come up a lot more.
And even more off topic (sorry), what makes Lua better/different than other scripting languages?
EDIT: On jacobwcarlson suggestion, I Googled Lua vs Python, and found this Wiki, http://lua-users.org/wiki/LuaVersusPython Not a speed comparison, but gives a fair amount of difference in the actual languages. And yes it is on a Lua users site, so may be biased, but on my very light reading didn't seem too bad.
Lua is a language designed to be embeddable, Javascript is a language that didn't even had the chance to be properly designed.
Although I'm one of those Lua "unadopters", for me it's better to simplify stuff to my audience, and I have considered seriously to use JavaScript for my next project instead of Lua.
Both javascript and lua were designed for very similar goals. It just so happens that the designers of Lua had more time to do it- plus they aren't burdened with the need to always be backwards compatible, so lua (now at version 5) breaks scripts written for older versions.
I'm pretty confident that if Lua were as widespread as JavaScript is, a backwards incompatible change would be less likely to happen, although with Corona SDK, I'm also confident that Lua will have an opportunity to shine :).
I"m not sure that "widespread" really would do it. The other difference between Javascript and Lua is that- while Javascript has been embedded in adobe software, modified to become actionscript, and is the scripting language in some games, its primary use has always been the web- with its specific DOM api. The web carries with it the backwards compatibility burden.
Lua doesn't have to be backwards compatible because nobody has to upgrade to the latest version of lua- and there isn't much of a standard library to break anyway- All the things you'd traditionally use a library for are provided by the outer application lua is embedded in- an application likely not written in lua itself- and so if you do decide to upgrade your app/game the only thing you break is individual scripts.
With a widespread adoption more security-related issues and bugs get discovered, with new security-related issues and bugs comes new fixes, and those fixes (especially the security-related ones) IMO are the incentive to update.
Whenever you release a new version with backwards-incompatible changes you discourage your audience to update and they fragment.
Your product exist because it solves a problem, and the moment your product gives more problems than the ones it solves, you discourage your users to use your product and they begin to look for options, and if an option that meets their needs doesn't exist they will stall (ex. Windows XP).
This means extra effort, since you have to maintain at least the most used major versions, and at the very least provide security updates to your users. Fragmentation is a <s>headache</s> migraine that you want to avoid whenever it's possible...
With a widespread adoption you have to evaluate deeply whether the fragmentation troubles are worth the value the backwards-incompatible changes will provide. It's not the same trouble having a hundred users, than having a billion users.
You're not wrong, but I think with lua the fragmentation problem is pushed out to the app developers who embed lua in their various games and applications. Do the developers of lua concern themselves much with this? I suppose slightly, but mostly in the form of documenting what's different and how to convert old code to new code. The lua philosophy seems to be that a simpler/smaller implementation trumps backwards compatibility.
You are also right, but when a project has small adoption, usually the users are people that feel identified with and like the project.
But suddenly the project becomes a product, and the product gets adoption (every time more).
The users will use your product because of different reasons (ex. it's what other people use / it's what can solve better X problem / it's what I got recommended / etc.), the users that like and feel identified with the project become a small niche in comparison with the people that need the product.
The users become the ones that shape the product, you have to balance between:
Feature A. Which is what you want to do for the project.
Feature B. Which people are telling you they need for the product.
Will you develop exclusively "Feature A"s, because you are following a philosophy?
Think for a moment what would had happened if Microsoft had adopted Lua for IE3 instead of reverse engineering Netscape's JavaScript (assuming that IE would have still won the 90's Browser Wars thanks to Lua). Are there flying cars in that parallel universe? Is Lua uglier than today's JavaScript? Has Douglas Crockford written Lua: The Good Parts yet? :)
I'll leave the pros/cons of the language itself to others, but two of Lua's most attractive aspects are its size and speed. The interpreter is something like 200k and is built to be embedded into anything. For instance, RPM has a Lua interpreter embedded into it and here's Dino's paper about using it in 'sploits: https://www.usenix.org/legacy/event/woot07/tech/full_papers/... Benchmarks are notoriously unreliable but I encourage you to Google around for Lua v X language. It's _very_ peppy.
Lua is elegant, small and fast, especially when you're using LuaJIT. It's the language I reach for first when I need to embed a scripting language in a system (perhaps to replace configuration files).
Its only real drawback is a lack of libraries/package manager compared to, say, Python/Ruby (respectively). I guess some people might miss built-in support for classes.
>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.
That's one way to see it.
Another is that we don't erase them: we put them to use so programming can be more widespread, easier and more ambitious in scope.
(E.g. you cannot practically write a 10.000.000 line program in ASM, whereas you can in C. Or you cannot have everyone be able to write a 200 line high level program that does something complex in C, but you can in Python).
You can. Rollercoaster tycoon was originally written in pure ASM.
Allowing programming to be more widespread is a noble cause, but there comes a point (and I think it is approaching rapidly) where you layer so much abstration between the machine and the programmer, that they're guaranteed to write poor, or at least slow code. We need to find a middle ground, and I think javascript pulls in the wrong direction to this.
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.
Here is one way I can think of - add a layer to run a subset of Scheme on this :)
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.
Forgive me for not being hip but why try so hard to put JS in new places? It seems to be just an unfortunate historical accident that JS is one of the most popular languages in the world - does anyone actually like it compared to other modern scripting languages? Could we invest in CoffeeScript instead, at the very least?
I like my functions as first class citizens. I like my prototypes and my inheritance model. I like my callbacks and my closures. I like how I can move from client-side, to server-side, to my TV, all with the same language. I like how easy it is for beginners to produce something useful and for seasoned developers to produce something good.
There are many other languages that share such traits but Javascript is one of the few that can be picked up by beginners interested in any field (eg: games, web, apps) and keep surprising you. It is extremely powerful in the hands of those that devote time to learn how things work. Its one of the few languages that you can learn as a beginner and keep with you as you become a better programmer.
I don't think it should be the only language someone knows but it should be a language that everybody knows.
Check my second paragraph, I quote some of things I like most in js as a language. Nothing there is exclusivity of javascript and many other languages implement the same features but I do enjoy javascript as a language and the fact that it is evolving, successful and ubiquitous helps a lot.
I'm not who you originally asked, but I share his sentiment that javascript is a nice language. I've used python for years, have a few open source applications with Java, and written several scripts for my own purposes in C. I've also explored C++, haskell, scheme, ruby, and MIPS assembly. Not a whole lot of PHP. So I use javascript for everything? Not even close. But I still like it.
In recent times I have delivered commercial products in PHP, Python, Ruby and LiveCode. In the past (way past more than 10 years) I used to work with VB, Delphi, REBOL and some Java. While I was coursing engineering, we learned scheme (its great!)
CoffeeScript is JS. And to be more honest and judgemental, CoffeeScript is the sweeter-but-poorly-documented Javascript.
The reason people are attempting to put javascript everywhere is because they can and because others enjoy it. And those who do enjoy JS, know what parts of JS are to be avoided at all costs. And I actually like it compared to other modern scripting languages for two reasons:(1) I don't have to worry about whether my end-user will have to worry about installing 100 dependencies to consume my code/service (2) I can choose how robust my setup is (Closure Compiler) or how sweet (CoffeeScript), and spend time sharing my setup with others who like the language instead of using proverbial sarcasm on topics about languages that I don't want to use.
But the one-page manual of coffeescript is far more useful to users than those looong specifications. No document about the syntax is better than the annotated source of the parser. And you can find specifications about all kinds of javascript runtimes elsewhere, they document the coffeescript runtime too.
Language specifications are important for interoperability. They are very useful for people who write tools like smart IDEs or linters. They are also interesting for people who want to create their own VM or compiler. There are various JavaScript and Java VMs. There are also various C and C++ compilers.
But there are also users who read them if they think that some particular behavior is puzzling. Then they check the spec to see if this stuff really is supposed to happen or if this is something which wasn't properly specified.
For example, there was a 50:50 split when it came to the behavior of SVG masking. As it turned out, that part of the spec was just confusingly written and the compliant behavior was actually really silly. The spec was changed and now every browser does the same intuitive thing.
Without this "central authority" there wouldn't have been a way to get this fixed.
Dart is another interesting example. They had a specification since the beginning and every part of the ecosystem follows it. This way, different teams (and even different companies) can create all kinds of tools which all have the same precise understanding of the language. Naturally, this also helps with identifying spec issues.
Without a specification, you have to reverse-engineer the behavior and you might end up being forced to replicate some really nasty crap. Some of JavaScript's warts were set in stone this way.
I like JavaScript. It is a very intelligent language, far ahead in its design than more recent products like Dart. If you was not insanely focused on its drawbacks, you could see its qualities too.
Your post is content-free. What do you consider explicit advantages of Javascript over Dart? Because to my eyes Javascript looks like a similar language with no type system and terrible scoping.
I enjoy JS a lot, and will frequently choose it over Ruby or Python. A functional style plays nicely with a lot of the problems I'm solving, it's nearing ubiquity, and there's lots of big names and smart people working on optimizing it even more.
In my day job, we write mostly Coffee - which is little more than a preprocessor to JS, IMHO. It's definitely nice to have, but I don't consider it an independent language unto itself. If you know JS well, it shouldn't take more than a day to get up to speed with CS.
It's disappointing to see the false "JavaScript is functional" claim thrown around time and time again.
Just because it has first-class functions it does not mean that JavaScript is a "functional" language.
JavaScript does not promote the use of pure functions, referential transparency, and the minimization of state.
JavaScript does not encourage the use of recursion.
JavaScript has an atrociously broken type system, rather than a robust and theoretically sound one.
JavaScript does not offer pattern matching and other functionality offered by modern functional languages.
In fact, it goes out of its way to promote a very imperative, non-functional style of software development, even when efforts are made to try to use it in a functional way.
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.
C/C++ is always in one corner because it's the go-to language (heh) for code that needs to do direct hardware access and manipulation.
That said, if I don't strictly have to run C/C++, I'd much rather run Haskell or Python. And you'd be surprised where you can run high-level languages like Python; one project I work on runs Python in the GRUB2 bootloader to test BIOS and hardware, giving Python full ring0 privileges, raw memory access, ACPI method invocation, and SMP support. Some of the Python standard library is missing (an HTTP server, for instance), but quite a bit of it is available. See http://biosbits.org/ for that project.
Well I have been trying to play around with LLVM on ARM Cortex-M4 micro controllers specifically the STM32F4 series of my controllers there is a github project that tries to use Clang.
Now if I had the time and experience I wanted to try and compile this library called py2llvm. The library that can compile static variables and python syntax into LLVM bitcode with C like performance. I think that is the best of both worlds.
I'd expect Javascript programmers dwarf Lua programmers by a couple of orders of magnitude. At least one OOM if you want to limit to people who only know the language "well."
In the game programming industry (PC games, not iOS/Android games), the two most popular languages are C++ and Lua. That's probably part of the reason why these two languages keep getting brought up in this thread to compare against Javascript.
As someone who has come around to Javascript after many years avoiding it, I think I can answer you: people like Javascript for a similar reason to why people like Python. As long as you stick to a strict set of conventions, Javascript is a very compact and manageable language, with a bit of extra flexibility to spice things up due to its prototypal nature.
With Python, you don't have to worry about the conventions part, since there is one "Pythonic" way to do everything. But at least with JS there are only a few different standard ways to implement, for example, OOP. So once you've gotten used to it, when you read someone's code, you can quickly notice what style they use and contribute your code to match it.
My biggest remaining gripe with Javascript is the lack of a good base set of libraries for container and string manipulation. Sure there are packages (like Underscore) you can use, but it would be nice to have them as a standard part of JS.
Same same. Though I'm happy with having a lot of stuff out of the stdlib because we know where that kind of things leads. As long as performance is good enough, that probably won't be a problem and discoverability is still ok (agreed the ecosystem not yet too vast although we're getting there). My gripe is with all the unfinished stuff in just about any javascript library out there.
Any chance you could point out a couple of good resources that cover the "strict set of conventions" you mention for Javascript?
I've been dabbling in Javascript projects for a while now, and one of my biggest frustrations has been that I haven't been able to find any great resources that cover best-practice code design (above the level of style guides that cover mainly syntax issues). It would be great to have a couple of resources that cover the "right way" of doing things.
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.
Non-string values are not valid hash keys. Operations that should be type errors fail silently and return nonsense. The prototype system is less powerful than the OO system of basically every other scripting language. The language will never have continuations, so people who want real control flow are stuck using preprocessors to generate callback spaghetti. Encoding a particularly rigid mix of dynamic and lexical scope into the language specification, such that everyone must be exposed to dynamic scoping much of the time, is one of the worst ideas I can imagine.
> Non-string values are not valid hash keys. - ES6 Maps
Yes, this is a good thing :)
> The prototype system is less powerful .. - No. Just different
Javascript let you use prototypes to cause map lookups for absent keys to fall back to a different map. Lua lets you use prototypes to override every operator, make the object callable, override map lookups for absent keys, and override assignment of new keys. All of these operations can be made to call into arbitrary functions the user provides. Python, an OO scripting language, provides all of the same features.
It seems to me that among these three languages there is a greater difference between the more powerful systems and the less powerful system than between the prototypal systems and the OO system.
> The language will never have continuations.. - Generators help here. We use them with node --harmony
Python also has generators, but you still need greenlet or stackless if you want to use coroutines. The inability to suspend from a subroutine is a deal breaker. Generators are probably nice for writing generators. For writing control flow, Continuation.js seems like a better choice.
> Scoping. - Fat arrows and block scoping coming in ES6.
=> lets you use a lexically scoped this, which is likely a dynamically scoped this from an enclosing lexical scope. This sounds useful, but it doesn't really make things less messy.
> Sure if you prefer static typing then JS is not for you.
I did not say anything about static typing. Most dynamic languages are not forced by their specs to coerce disparate types into utter garbage. I invite you to type the examples in the Wat talk into a REPL for any other dynamic language and see how many of them produce exceptions.
> Continuations seem to be rare among other languages you could choose. Personally I have only seem them in LISP, what else is out there?
Before answering, I will point out that coroutines are equivalent to one-shot continuations, and coroutines that can be copied are equivalent to multi-shot continuations. Then, I am familiar with continuation implementations in the following languages: Python [1][2], Scala with any JVM runtime[3], Any JVM language with a particular runtime[4], C[5], Lua[6], Julia[7], and C++[8]. Of these, the ones for the JVM, C/C++, and Lua[9] are multi-shot continuations or equivalent to them, while Julia and Python are a bit more limited. I am not familiar with many languages, so I'm sure I've missed a lot of instances of this sort of feature.
> I would love to use LISP, but the libraries simply aren't there. Last time I tried Racket, there wasn't even a library for JSON.
I can't really speak to this because I haven't spent time trying to build real software using lisp.
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.
It takes less than an hour to learn and get used to it if you know the standard Java-style OOP already. It's worth it and it'll give you a whole new opinion on what OOP means.
I know how it works, I just find it worse, by far. There's a whole lot more overhead to getting it working, specifically all of the foo.prototype stuff, and it doesn't require that everything be together.
Sure, it's kinda nice that you're able to extends objects later on, but I'd rather have everything neatly declared in one place.
It definitely does not "give me a whole new opinion on what OOP means", it furthers my opinion that I'm not a fan of JavaScript.
It's very good to see more and more people openly admitting that JavaScript's prototype-based OO approach just isn't
practical.
For far too long now we've had to hear JavaScript advocates go on and on about how good JavaScript's approach is. Yet over and over we see developers being forced to fake a limited subset of class-based OO one way or another, just to get their work done effectively.
Of course, there are multiple ways of faking class-based OO in JavaScript, with varying degrees of compatibility with one another. In any sizable JavaScript code base, especially if third-party libraries are used, these incompatibilities can become a very real issue, very quickly.
This is one of the things that the JavaScript community should have addressed years ago.
>> In any sizable JavaScript code base, especially if third-party libraries are used, these incompatibilities can become a very real issue, very quickly.
Whether you use constructor functions, object literals, or the module pattern to structure your code in an OO-like manner, they all result in 'functions hung off objects' which can be called in the same way: object.foo(), I don't see the very real compatibility issue you're talking about.
>> It's very good to see more and more people openly admitting that JavaScript's prototype-based OO approach just isn't practical.
It's plenty practical, I will welcome ES6's class keyword for the clearer semantics, but this is simply vague FUD.
Your entire complaint is very superficial and easy to fix with any convention you like. For example: http://jsfiddle.net/AXTdj/3/ I included "overhead" calculations.
@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).
1) There are very fast implementations in production, as well as an arms race between some of the world's most powerful titans of software development to outdo each other at js vm performance.
2) It is a thin abstraction over the Reactor Pattern, which is very useful for certain kinds of event-based applications.
3) Very lively and robust package ecosystems in npm (node) and jQuery (web). Virtually all packages are async by default.
You do understand that CoffeeScript compiles to JavaScript, and that by supporting JavaScript they're supporting CoffeeScript, in addition to TypeScript, right?
JS is great - it's so hackable, via simple straightforward syntax that's familiar to anyone who programmed in c,c++,c#,java,php and is similar in ease of use to python and ruby - why on earth would you think it's a bad thing... Javascript is easy - few constructs that together can build just about anything is a big plus IMO - to each is thier own right
Because its the current trendy thing. And chasing that dragon isn't necessarily a bad thing if it gets people in the door. Sure its an evolutionary dumb step in some ways but lowering the barrier to entry means that ideas that might not otherwise come to the space could get a chance to grow. Or if nothing else the trendy attention means more libraries get written, which helps someone else down the road.
There are a lot of blind optimism in that statement, but we all know that the best tech doesn't win. What wins is the good enough-ist tech that also pops enough buzzwords win the to interest of the dude that claims to only care about the best tech.
Plus, Lua isn't controlled by a creepy asshole who thinks the NSA is essential and says stupid shit like "Who's ever heard of government misusing information?"
I'm curious. I persume, with quite powerful hardware, task's not going to be trivial and may require some concurrently running processes.
JVM has threads. Akka adds actors (those seem quite nice when used with Scala). Does Lua/LuaJIT offer something simple-looking-yet-powerful in that area?
This comment is a bit incoherent, so I'm not sure if I'm responding correctly at all. Your C/C++ program can contain any number of Lua states, and can also contain an infrastructure for passing messages between these states. The states themselves are single-threaded. Within a single Lua state, you can have any number of coroutines, but these do not work like JVM threads or goroutines; they must be scheduled explicitly.
Full disclosure I'm not a JavaScript programmer. I dink around with it. I can work with it. I understand it enough to maintain the code I need to at work, but I'm not a "JS Guy".
At the heart of my programming heraldry is C. From there I branched out into C++, Java, Perl, C#, etc.
In effect you are comparing JavaScript to Assembler, since CoffeeScript compiles to JS. I'm certain most people would agree that this is a ridiculous comparison, because as quirky as JavaScript can be it is far easier to work with than assembler. I wish people would stop making that comparison (I've been guilty of it myself, but I've stopped as of late).
In my view, the popularity of JavaScript comes down to two things: Interactivity and instant gratification.
I first played with JavaScript while in college in 1995. It blew my mind that I could just put some code into a text file and load it into Netscape and see stuff happen. No compiling, no linking, just text making the browser do things, and unlike Java it did not require me to upload an applet and hope that my target user had a JRE installed.
Today you have things like Chrome dev tools and JS Fiddle where you can get even more of that.
The velocity of going from idea to web app (site) is a lot nicer for most people.
IMHO JavaScript is the programming equivalent of an LLC. It's quick to start, low capital investment, and doesn't expose you to a lot of risk.
Anyhow...that's my two cents that I had to throw in before more veins in my head popped.
When I see a device like this I like to think that people familiar with JS can now tinker with hardware devices. I know some people who are comfortable with JS but aren't engineers and they may not be willing to learn Arduino C.
Whatever language it is I'm glad prototyping devices are coming out at a cost that basically makes them an impulse purchase.
So, I don't really buy arguments like this. Would your friends who are comfortable with JS but aren't engineers actually be interested in learning microcontroller programming because they can do it in JS? When you move from scripting a web page to programming on a very limited embedded system, you're changing to a completely different paradigm. Instead of worrying about the DOM and AJAX, you're worrying about GPIO and PWM and interrupts. The actual syntax of the language is a rather minor detail compared to all of this. Now, I'm not saying that we should all be coding microcontrollers in ASM or AVR C, but what makes Javascript more approachable than, say, Arduino?
Because it takes a lot more time to learn another language proficiently than it does to adapt what you already know to a different platform. It's accessible.
It's my fervent hope that developments like source maps and asm.js will eliminate what it basically Javascript's sole competitive advantage; that it's the only language that runs in a browser.
If it's possible to write performant, robust code with good tooling in CoffeeScript/Dart/TypeScript/Python/Clojure/etc., then the peculiarities of Javascript become a lot less important.
CoffeeScript is JavaScript. There should be nothing stopping anyone from doing everything with CoffeeScript on this device, or anything that supports JS.
The goal is seamless integration between physical hardware and a web application without the need for a server on the device. Sounds pretty awesome to me.
Because everyone* knows JavaScript. I'd wager that the vast majority of professional software engineers work on the web, or very close to the web, and JavaScript is the lingua franca of the web. I mean just look at the front page of Hacker News on any given week. It's full of talk of JavaScript and new JavaScript libraries and new things to do in JavaScript. When you think about how many more people this can reach without them having to learn yet another language for a very specific thing, it makes sense.
*hyperbole, please forgive me for being not being completely literal.
Everybody thinks they know javascript, but on the contrary nobody actually knows it. It's a very twisted and powerful language. It has many quirks and many unknowns.
Most of the time if one thinks s/he knows javascript, actually s/he knows a higher level abstraction library and DOM built on javascript like Jquery.
Some people do know javascript. Implementations differ, but are getting more standardized as time goes on. Without the DOM and browser environment APIs, it gets a lot simpler. Do you think fewer people actually know javascript than actually know C++?
C++ is a bad example. C itself is mindblowinly complex, and C++ layers more on top of that. A better example might be Python, or possibly Lua. Languages that have been designed, rather than grown organically, unlike C++/C/Javascript.
Yeah, but a basic level of javascript is often all that's necessary.
I had quite a few non-developers on my team, who knew enough javascript to have a "good enough" idea what was going on with the code, without having to bug me all the time.
> I'd wager that the vast majority of professional software engineers work on the web
Yes, a majority of prof. software engineers who work for internet companies work on the web. But then there's also stuff like embedded, systems, databases (not the ones you hook up to some scripting language to generate html), medical, aerospace, industrial processes, etc.
The software industry is huge and only a small part of it is web related.
> I mean just look at the front page of Hacker News
It's like assuming San Francisco was a model for all other cities on this planet. It's all about your local bubble. For you maybe really it looks like everyone (including your local coffeeshop owner) could win a JS hackathon. But for me I barely know an engineer who's fluent in JavaScript. Everything is C++ here.
And? That's brilliant, as it provides some progression after learning the language! Once you're confident with Arduino, you can move onto C++, from there ASM, etc...
I've dealt with these kind of programmers on numerous occasions. While they may claim to know other programming languages, they usually don't know much about them at all, in reality. If they do know another language, it's PHP, which is just about as bad as JavaScript in most respects.
Any programmer who has real experience with a variety of different programming languages will become very aware of how inferior JavaScript inherently is.
JavaScript's problems go much beyond the quirks or oddities we see with programming languages in general. They're severe deficiencies (the lack of proper modules or namespacing, and the lack of proper class-based OO), or inexcusably stupid design flaws (semicolon insertion, its broken scoping rules, its broken type system, its broken prototype-based OO, its broken comparison operators, and so on).
No intelligent, experienced, self-respecting programmer will want anything to do with such a ridiculously flawed and broken language. They surely will not see it as good as Python or any other language that isn't rife with the unjustifiable stupidity that permeates every aspect of JavaScript.
Well, that's just unnecessarily offensive. I'm proficient in Python, Java, and C, and was at some point also fluent in PHP, Ruby, and Lisp. While I wouldn't particularly enjoy coding in Javascript, CoffeeScript is, to date, the best language I've worked with. I debug in JavaScript, so I'm not that far away from it.
Why is "class-based OO" necessary? There's nothing wrong with prototypal inheritance. The way modules are done in Node is pretty powerful compared to other languages I've used. The scoping rules are different, for sure, but I don't really see why you'd call them "broken". They're internally consistent and easily comprehensible.
Semicolon insertion is, admittedly a problem. The solution, of course, is to put in your own semicolons. If you do that, and use something approaching reasonable whitespace conventions, there isn't really a problem. JavaScript's `==` the like are, for sure, broken, but that's nothing a `===` can't fix. It's not like the other languages you mentioned wouldn't have issues without reasonable conventions.
There's nothing "offensive" about pointing out realities, even if they may be painful for some people to accept.
I find your arguments somewhat odd. You do openly admit that you "wouldn't particularly enjoy coding in Javascript". People don't say such things about good programming languages, especially when arguing in favor of them to some extent.
I also find it odd that you argue that there's nothing wrong with prototype-based OO, yet claim that CoffeeScript is the best language you've worked with. One of CoffeeScript's most useful and important features is that it adds very simplistic class-based OO to JavaScript. Go look at the example code in the "Classes, Inheritance, and Super" section of the CoffeeScript home page to see what I'm talking about. The CoffeeScript code is tolerable; the JavaScript that's outputted is horrendous. Hand-written JavaScript is often just as bad, if not worse.
The various JavaScript "module" systems are purely hacks. They abuse existing language features to fake modularity, poorly. They're nothing like the proper module support of other languages. And at least you admit that semicolon insertion and the broken comparison operators are serious issues. Many other JavaScript advocates refuse to, for whatever reason.
There's nothing wrong with admitting that JavaScript is a really bad language. I think you know that it is, and want to admit it, and I think you should. It doesn't deserve to be defended, because its problems are generally inexcusable in every respect.
> There's nothing "offensive" about pointing out realities, even if they may be painful for some people to accept.
The problem is that your comments about JS tend to contain more hyperbole and opinion than undisputed reality.
JS obviously has flaws. But so does English. It's good to have a natural language that a large percentage of the world's population, across nationalities and ethnic groups, can speak. I think the same applies in programming. Programming languages are not just for telling a computer what to do; they're also for collaborating with other programmers. And once a code base is written in a particular language, it's often hard to make a case for rewriting it in a different language. So why not use a language that is popular, is cross-platform, is vendor-neutral, has multiple optimized implementations, and is likely to remain popular and well-supported for many years to come? JavaScript is that language.
FWIW, I have much more experience with Python and Lua than with JavaScript. I also do some work in C++. Yet, despite JavaScript's flaws, I'm defending it as a general-purpose programming language.
JavaScript has issues, but they are largely syntactical. Yes, `==` means something different than it does in every other language - but it is still a useful construct (if not worthy of its own operator). Yes, `Class.prototype.method` is overly verbose, but in CoffeeScript you get clean syntax without losing the beauty of prototypical inheritance.
The strengths of JavaScript, on the other hand, are deep. Everything is an object, functions as first-class citizens, the inheritance model, etc. The callback-based I/O of Node.js wouldn't work nearly as well in any other language I've seen, because JavaScript is such a good language.
I will take a language with syntactical deficiencies but a beautiful underlying model over the opposite any day, and I don't see anything about that statement that indicates that I'm a poor programmer who's only been exposed to PHP and JavaScript.
There's nothing wrong with admitting that JavaScript is a really bad language.
Your use of the word 'admitting' is peculiar. There's nothing wrong with claiming that JS is bad. There's also nothing wrong with claiming it's good.
I enjoy programming in CoffeeScript more than any other language I've used (Ruby, Python, Objective-C, a little Java, a little C). Plus, as dynamic languages go, it's fast. To me, these two things make CoffeeScript a fantastic language.
And since CoffeeScript is just syntactic sugar on top of JavaScript, well, I suppose JavaScript must at heart be a fantastic language too.
(Evidently today's my "someone is wrong on the Internet" day).
> I also find it odd that you argue that there's nothing wrong with prototype-based OO, yet claim that CoffeeScript is the best language you've worked with
You don't have to use the OO inheritance features in CoffeeScript in order to like it on the whole.
This is the key. With good conventions and tools it is perfectly fine language. The concept of "Programming into one's language" from Code Complete applies strongly:
> Programmers who program "in" a language limit their thoughts to constructs that the language directly supports. If the language tools are primitive, the programmer's thoughts will also be primitive.
> Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.
I disagree with Coffeescript though, nothing will make that shit readable to me. :P
I've met talented JavaScript programmers. They're just quite good at using other languages, too, and thus choose not to use JavaScript whenever possible.
Can I ask why it worries you? Honestly just curious. Is it the performance hits of more levels of abstraction? Or fear of all data being in the "cloud"?
Personally it worries me because people can build whatever they want and call themselves "programmers". It encourages a state in the industry when knowing about data structures, hardware, turing machines or the other fundamentals of computer science are considered unecessary. Perhaps they are, from a business standpoint. However, it will eventually inhibit growth of the discipline as a whole.
A common rebuttal to that is "it allows people to get into programming more easily". I personally think this is horseshit. There are a multitude of ways to get started with programming, and javascript is in many ways the one that teaches the worst practices and patterns of them all.
I understand where you are coming from, and I don't like the "it allows people to get into programming more easily" excuse either.
But I don't really think it will inhibit growth. I think that it is more likely just to create two main groups of people that call themselves programmers. The people that know HTML and jQuery and the actual programmers. I don't think it will do anything to the growth of real programming, it just might mean we get lots of people calling themselves programmers who really aren't. But that happens already.
I think that segregation in of itself can be dangerous too though. People will get stuck in the web programmer mindset, and never progress if they're interested in anything else.
You seem to think these programmers are content with simply learning only what they need to know and calling it a day.
As a self taught developer, I find it offensive that you think I would go through all the trouble of teaching myself how to code, and then rest on my laurels, like I wasn't inherently curious and thoughtful.
Since learning Javascript front to back, I've developed a curiosity with strictly typed languages, assembly, computer science, Big O notation and other (what I consider) hardcore disciplines in computing.
Javascript was my gateway, and I love it to death, but I'm not a javascript developer any more than a C developer is simply a C developer.
I don't intend to offend you, but I think you illustrate a problem with many programmers who have come into the field with a self-taught JavaScript or PHP background, and without any sort of a formal education.
Type systems, complexity analysis, and assembly language programming, for example, aren't "hardcore disciplines in computing". They're the basic foundation upon which the rest of our knowledge is built. They are among the minimal level of knowledge that all programmers should have.
When you understand concepts such as those first, and are exposed to JavaScript later on, it's plainly obvious how inexcusably bad JavaScript is. While theory may not always work well in practice, JavaScript goes out of its way to ignore sensible and practical theory in every way possible.
People starting with JavaScript (or PHP; JavaScript isn't alone in being a bad language), but without this basic theoretical knowledge, don't seem to realize how bad the language truly is. It's unfortunate to see them not accept and admit to these flaws, even after the learn that there are much better ways of doing things.
> Type systems, complexity analysis, and assembly language programming, for example, aren't "hardcore disciplines in computing". They're the basic foundation upon which the rest of our knowledge is built.
Your second sentence pretty much defines "hardcore". The "hard core" of anything is what supports the rest. Originally the term is from the mid-19th century and refers to a layer of broken stones and bricks that provided support for a building project, commonly roads.
Programmer may have been an elite title at one time, but now it's just like saying gardner, chef, or scientist. You just have to work a little harder to figure out whether or not someone is a moron. There have always been morons and there always will be. I may be one of them!
To quote Sturgeon "90% of everything is CRUD". Majority of people that get CS now is due to money (how else to justify the expense of a diploma?), not the appeal computers have, and it's been like that for a while.
Lowering barrier to entry is +EV move, almost always. It multiplies crud but more importantly multiplies the 10% that are worth the crud.
As opposed to studying for five years in a college, learning Java and programming in Java exclusively, never learning anything outside the Java and never perfecting?
People's curiosity is what motivates them to experiment and learn new things, not how or what language they learn (I started with Basic which apparently causes brain damage and I'm getting along fine). If they are curious on their own, they'll pick up data-structures/asm/c etc.
> As opposed to studying for five years in a college, learning Java and programming in Java exclusively, never learning anything outside the Java and never perfecting?
Various smartcards use subset of Java 2 bytecode (search for "Java Card") although I'm not sure if it's particularly better or worse than running some other kind of instruction set.
Jazelle basically turned into an extension of Thumb2, where there are few extra instructions for things like bounds checks. It should theoretically help make faster JITs in general (not necessarily just JVM ones).
To add to this, abstracting away from hardware is exactly what C (which most people consider low-level) was built for. No one wants to write assembly, and even less people want to write 0s and 1s or punchcards.
Successfully-executed abstraction is a wonderful thing, people have been trying to abstract away (but retain performance) of C for decades. I welcome newcomers, maybe someone will get it right
Agreed, the state of art of most microcontroller manufacturers these days is to push out a (usually buggy) Eclipse based IDE with undocumented C libraries. They all have their quirks and issues - noone has got it right yet from the developer's point of view. This seems like a step in the right direction, albeit taking a big performance hit.
I completely agree. I'm a front end developer recently out of college and I decided recently that I wanted to expand my knowledge and learn hardware. This seems like a good place to start given my knowledge of JavaScript
If your college education for becoming a developer didn't teach you a lower level language it failed you. Even at my small liberal arts school we use multiple languages (they may all be really, really similar, but they're different languages), and work on low-level things.
I'm aghast that a CS education wouldn't include at least Java, especially considering that a large number of schools switched exclusively to Java at one point.
I learned C++, Java, Scala, Python and Ruby. I just prefer and am most familiar with Scala & JavaScript these days because I use Play. While I could go back and refresh my knowledge of C, it's nice having a device that uses the language I already use on a daily base given I have little to no experience in actually working with hardware.
As to your point to zhemao about learning new things, I said in my original post that I wanted to learn new things, in this case, hardware.
A general attitude that I've seen as a new user on HN (and a new developer): "If you don't learn something you enjoy (messing with computers) in exactly the same way that I did, you're wrong!"
For some, there's no joy in complexity or inspiration in learning. Just wrong or right--generally with "my way" being right. What a shame!
Seems like a lot of that energy would be better spent making an equivalent device that runs <language of preference>. Want it to run coffeescript? go make a product designed around coffeescript. Want it to run Lua? Go make a product designed around Lua. etc.
The market has room for diversity. Just because it's not the diversity you prefer, doesn't make it any less valid.
But why a dedicated device? Why not just a JS -> ARM/AVR/whatever compiler? Then you can run it on microcontrollers that you can actually build up from. One of the best things about arduino is that it's based upon the ATMega platform. Once you've got the hang of the arduino language, you can progress to embedded C (on the same device), then onto assembly if you really want.
Once you've got to that level you've got a whole family of related microcontrollers that you can move onto from the same principles. With this javascript device you've got no such thing. You're stuck in a dead end if/when it turns out not to have what you need, as you can't progress to "the next level".
Any sort of compiler for JavaScript could only support a subset of the language, unless you shipped an interpreter alongside the compiled code. This subset might be unfamiliar enough to the point that moving to a new language wouldn't be that much harder for some programmers.
I also see nothing on the site to suggest that C/C++ (at least) couldn't be supported, although I have no clue how much work you would have to do yourself (likely too much).
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.
The BBB and the Raspberry Pi are designed to be relatively high-power (both computational, and power draw from DC) devices running a true multiuser OS.
This thing is more akin to an Arduino Micro or a Teensy - a low-power controller that could run a very long time on a tiny battery, no OS to speak of, just a single loop of essentially real-time code.
I just made a hardware clock for my PC (7-segment LED display mounted in a CD-ROM bay slot). I used an Arduino Micro to drive the display.
I may build a dedicated media server at home. A RasPi or BBB would be perfect.
I'm thinking to launch a stratospheric balloon. I need something to hold together and drive a GPS sensor, temperature sensor, VGA camera, SD card, and radio transmitter. Total weight and power consumption are severely limited. An Arduino or Teensy would be great.
Do a wall-mount big LCD screen at the office, showing the vital stats of our website in real time, for all to see? A RasPi or BBB.
Or you could go even more bare-metal and do everything with an AVR that costs $1 and a few components that you recover from the last floor sweep, like this:
Yes, but if you're using javascript you're probably not aiming for long battery life or high performance per dollar. Tessel is not like an ATmega 8; it's like a BBB.
I agree about the arduino and batteries, but this board is a bit different.
It uses external memory which takes more power. It uses javascript which could take much more power. And the wifi also might not be low power. So it's not clear yet how low power it is.
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'd say they've added some value.
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.
And what happens when you need to specify a pin mode on the Tessel? If you don't have at least tri-state support (which isn't compatible with human-friendly abstractions like "blink"), you're going to burn out a lot of sensors.
Most modern microcontrollers have anywhere from 3 to 5 possible pin states, and I don't think it's possible to safely wrap these up in a nice, human-friendly function like "blink".
For example, on a lot of ARMs, you have:
In, no pull
In, pulled up
In, pulled down
Out, up
Out, down
and on AVRs, you have
In, no pull
In, pulled up
Out, up
Out, down
You necessarily have to have ugly secondary functions like "pinMode".
Also: peripheral muxing, interrupts in input mode, connecting a timer as PWM output to a pin (which is basically what blink is probably doing). In input mode it might also have schmitt triggering.
Where's the blink getting the timer from? What happens if I update the main PLLs? I'll refrain from making assumptions however until I can see their driver libraries. I'm hopeful, but having played around with the 1830 it's not a simple chip.
I don't see a price yet for this one. I like the pi (and the beaglebone) because they've already got the network hardware, but the gpio isn't as robust as on the arduino (3.3v vs 5v, very low current capacity on the pi, and no analog io).
I can't say I particularly want the javascript, but if they've got wifi and arduino compatible gpio for ~ $25, then I can find a use for it.
BeagleBone Black has a huge number of gpio pins, it's one of BeagleBoard's major selling points over RasPi at this point. I'm fairly certain the BeagleBone Black has more gpio pins than the Arduino.
BeagleBone Black also has a real-time module (effectively, a limited microcontroller on the same die as the CPU), which I expect could make for some sweet libraries.
No it doesn't, but since it has USB ports you can augment it with a USB wifi module. A word of warning though. If you're thinking of buying one of these, make sure to check that it has good Linux support.
I had this thought was well. As as physics major and an EE major, it's a (somewhat humorously) terrifying concept, at some level.
Now this has more or less been discussed to death in the threads above and below, but while I don't necessarily think running JS on a uC is a great idea, I don't see a problem with letting non-hardware-versed folk write low level code. People who know hardware will probably not use it for anything critical, and if it makes someone's life easier without endangering others or utterly diluting the community (knock on wood...) then so be it. There's no reason to be elitist about low level programming.
At this moment my workspace consists of a bit of code for an 8bit microcontroller, a FPGA layout + VHDL, and a mixed signal high speed PCB layout I've been laboring over for the better part of two weeks. Take that, "low level" C! Now I could go off about how superior and/or necessary my low level methods are, but my friend who's working on an ASIC design might say something similar to me. There's always a lower level. As always it's a little bit about preference, and a lot about using the appropriate tool for the job.
I might have a problem if web developers started cramming JS onto arduinos and calling themselves competent hardware engineers, but (and I think most people in the field would agree with me) I suspect the likelihood of that happening is negligible. It becomes apparent very, very quickly when someone is pretending to know how to hardware.
So a lot of people have been complaining: "Why not language X, Y or Z instead of JavaScript?"
This to me makes me think that there is a space out there for a board that has some equivalent to vagrant/docker but for microcontrollers, where you can just flash the device with a image supporting a language of your choice.
Near as I can tell, there is nothing I read on the product launch page that says that JavaScript is supported at the physical hardware level.
Javascript doesn't support integers, so it doesn't seem like a good language for programming low level hardware. What about bit manipulation (XOR, AND, Shifting, etc)? This is critical for a lot of serial data communications and I/O controls.
JS supports integers; it just doesn't have an integer type so you can't always store, operate, etc on them efficiently (though a smart engine can do some of that for you). It has bitwise manipulation operations which treat the Number as a 32 bit int. There are also Typed Arrays which make it easier to work on raw binary data. Though yes, it can occasionally get a little finicky trying to interface a high level dynamic language with lower level stuff.
Anyway, for this I'm sure there will be a lot of libraries that handle that for you and expose a fairly high level api; like the blinking led in the example.
If you are a veteran programmer it may seem dumb but there are plenty of people who only know JavaScript (& HTML). Some of those people will be utterly blown away that they can control actual, physical "stuff" with those skills.
Nifty! I presume this is running on a Linux kernel? How much memory does node use? I would think that kernel + JS VM would chew up quite a bit of your 32 MB of RAM.
How would you run Node on it otherwise? If it's not running an operating system that Node already supports, it means they've done the very large amount of work needed to port a Javascript interpreter to a bare-metal environment. I'd be highly impressed if they had actually managed to do that, but I'm doubtful. More likely they are using some stripped-down Linux kernel and userspace. A combination of uCLinux and BusyBox should work rather nicely.
It is very rare that I actually put my email into one of those "sign up for updates" things, this is pretty awesome, can't wait to hear back from you guys
This is the most elaborate troll i've ever seen. Kudos to the team for creating what is literally the physical embodiment of everything I hate about technology.
Reminds me of that time Sun made the Java CPU and the JavaStation. A hardware implementation of the JVM. It ran 20 times slower than the Microsoft JVM on an average Windows PC.
JavaScript is the most deployed dynamic embedded programming language in the world (consider all the web browsers on desktop computers and mobile devices). If we expland this environment to customer hardware, we also expand our view of UI/UX to a different level. We should thank Moore's law.
Are you implying that JS developers know more about UI/UX than others?
Most websites have horrible usability, ranging from "everything in CSS popups!" to "every site uses a different widget toolkit, deficient in new and exciting ways".....
I am not a big fan of the visual UI/UX either. My point is that there is more to the UI/UX than widgets and popups. With JS on hardware, we might have a new way to design HCI other than those pretty wireframes in Photoshop.
IMHO, JS is a laguage designed for APIs, which is good for exploring ideas and protyping. There is always a way to push the performance to another layer, like CSS boosted by GPU.
Yeah GUI widgets done in js in general for some reason have really poor quality and no attention to subtle details that make up the polished experience on desktop. Well at least they take 2 KB instead of 5 KB gzipped, that's totally a win.
Why? Because it uses JavaScript? I'd rather stick with my Arduino and use C. I don't get the whole "JavaScript Everywhere" meme, I'd rather use almost any other modern language (note the almost).
I perfectly understand your sentiment. When it comes to embedded systems nothing would beat C in near future especially those systems where safety matters.
The lab I am working with explores different ways to code robotic and embedded systems. From MIT's SCRATCH to Erlang we have used them all. One of the area that we have been exploring is of using functional programming languages to program embedded systems. (For example we coded a robosoccer using Erlang).
Being a Javascript enthusiast I always wanted to be able to write small JS programs that I could use to control hardware. Given that JS has good support for Functional programming languages as well, I wanted to try that as well.
There is no doubt that people are expecting too much from Javascript but I do believe this is a very novel attempt that I see a point in supporting. I do not think JS is a language that will find application in say automotive systems but it can certainly be used to program robosoccer in my lab.
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 memory overflow, it's my own damn fault, and I have the ability to fix it.
JavaScript is an acceptable scripting language. It's not my favorite, but it works. I just don't think scripting languages should really be used on embedded devices.
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.
JavaScript, and scripting languages in general (and, to be more specific, dynamically typed languages, too, but those tend to be scripting languages, anyways) tend to have a lot of gotchas, and when it comes to controlling physical things, I think that less gotchas are better.
Yes, statically typed languages just put a bunch of metadata in the code, but I think it's useful to have the guarantees provided by a static type system when your controlling things.
Like if you're controlling a robot arm. I'd rather have the type system make sure I don't try to do something stupid, like add a string to an int that's controlling the degree of the arm. Static languages make sure you can't do that, most dynamic language will let you do that.
It would definitely depend on the kind of project (for me at least). I probably wouldn't recommend writing the controller for some medical device in JavaScript. My impression was that devices like the one here are more for tinker projects, making LEDs blink and stuff like that.
Although I also don't agree that statical typing makes things so much more safe. And what can also happen is that in the world of statically typed languages bad workarounds are then invented for the inflexibility. An example would be the XML craziness that plagued the Java world for a long time.
There's not really much need for scripting on an embedded device. Embedded systems are meant to do a single task and run continuously. If he is already comfortable with C, he clearly doesn't have much use for a language like Javascript when it comes to microcontrollers.
On an embedded microcontroller, pointers and manual memory management tend to be less of an issue, as you're doing most of the stuff on the stack. I don't think I've ever had a reason to call malloc in an embedded C application before. If you were doing networking, however, it would probably be much more complicated. In that case, Javascript might be useful. But on the other hand, there are high-level languages that I would greatly prefer over Javascript.
Like Java, C is deterministic. Try adding a string and an integer in JS, what happens when JS is controlling real hardware, directly, and the coder said do this but the code (JS) does something else? I can't imagine coding medical devices with JS and hoping they always do exactly what their coders thought the JS they wrote would do.
C rules the embedded systems world. By embedded system I refer to the serious applications such as automotive systems and so on and not some funky new toy project done using Arduino.
There are some very good reasons why C can not be replaced by any other programming language when it comes to safety critical embedded systems. That is what separates men from boys.
As long as you write C correctly, which can be verbose when things get complex.
This project seems to be less concerned with the realtime aspect and more concerned with wiring things together. To me it functions as an OpenWRT/RasPi hybrid, with the Node runtime.
When you have a hardware that has got 512KB memory, 5 volt battery and you have to ensure that an event occurs every 10milliseconds it is C which beats JS or any other language hands down.
It was both a pleasure and a pain for me to read about this! Pleasure - because a language with closures is finally getting "closer to the metal" (even if it means an abstraction layer sitting in between). Pain - because that language is not a Scheme/LisP!
This would be so much cooler if I could tap into an REPL remotely and blink out a Morse code on the LEDs :)
PS: I have no idea what makes most of us go "cool!" whenever some form of remote control of a hardware device is presented :)
I'm curious about performance on this, compared to something like the Arduino YUN, which is basically a OpenWRT MIPS system (which uses a Lua UI by default) and an Arduino tacked on the side:
The CPU in particular seems quite underpowered assuming that they're clockspeed comparable, but I'm not familiar enough with the M-series ARM cores to give a proper opinion.
This is way better then Yun, IMO. Yun is an awkward design, I find very few reasons they had to put an 8-bit AVR and AR9 on one board. WTF. I really like this solution with a beefy LPC18xx and CC3000, it's totally cool by me.
I've been working on another embedded JavaScript project - first posted on here almost a year ago, and soon to go on KickStarter: http://www.espruino.com
This is really interesting though. It looks like they've got linux and node.js into 32mb RAM, which is seriously impressive. It seemed as if people were trying and failing on Carambola (but that may have been because it didn't use an ARM CPU...)
Did anyone find details (or have an idea) on power consumption?
<selfishPlug>
I'm the maintainer of nitrogen (http://github.com/nitrogenjs/service), which is a node.js based project to provide web services and client libraries for devices like this. Check it out if you are interested in devices like this!
</selfishPlug>
Hmm, I can see some potential difficulties with making JS work efficiently on that MC. It only has single precision floating point instructions, for one thing, and I can't tell how many cycles those instructions take. I'm guessing they'll just do a variant of JS that uses single precision, but even so, it seems like it would be hard to squeeze any kind of performance out of it.
I took a brief glance at the LPC1830 and it seems it doesn't have hardware floating-point at all. (None of the mainstream Cortex M3 products that I've seen do). Do you have better info on this?
So, I believe its FP support is through software and could be written to be double or greater precision. If this is true and if JS can only do floats, it would be bad news for many basic mathematical operations running on this chip. But hey, as someone pointed out above:
People don't want performance. They want libraries.
But with no FPU, count me out. I'd rather have my stm32f4. Just sayin'.
> If this is true and if JS can only do floats, it would be bad news for many basic mathematical operations running on this chip
By spec, JS only has double-precision floats. However, since that means that 32-bit integers can be exactly represented, V8 optimizes to integer calculations unless actually using floats becomes necessary. I would guess that on this device floating point operations are done in software, but also that they rarely occur in practice.
Certainly an interesting concept ... and I'm sure that will be some cool things that come out of this project.
I'm not sure I like the idea of a high level language, trying to control low level hardware. (seems almost counter intuitive)... however, if you wanted such a thing ... Node seems to be the way to do it... from both an accessibility and speed perspective.
Very interesting. I feel like I've been seeing a major trend towards Javascript-based-everything the past few months!
I wasn't sure if I should link this here, but this article really sparked a train of thought that brought me to write this:
http://blog.mcdougle.net/?p=54
Language-specific hardware has been done before, but do these really make sense? I remember excitement at the prospect of "Java CPUs". Did any of them become commercially or even technically important?
So, it's not actually JS in silicon (would that add much performance anyway, since JS is so dynamic? at best it would be asm.js-like, I'd guess...), but a supported language for an embedded device. I had a ghastly bizarro moment there: JS strikes me as bash + C syntax (not tsch)... in silicon...
I for one am really happy the JS era is here. Finally! Also don't listen to the haters. Ya'll know most of us make web apps so stop fronting. Though, I guess now I can make a battlebot too! JS is shaping up to be a great language and environment as more and more people get on board.
Great idea and marketing, but I just wish they'd chosen Go - I would have bought one in a second. Correct me if I'm wrong, but the lack of sane, static typing in JS just seems crazy to me when you come to writing low level code.
Had the pleasure to try it out last week and I found it incredibly easy to get things up and running. I think it has a lot of potential. Excited to see where this goes.
a good example of hardware hobyism and of the modern days eletronics renaissance..
maybe its not this one.. but the next computer hardware revolution will born like this.. the same way jobs and wozniak did in the 70´s .. from pure passion
hope my kids create its own gadgets like we did with legos in our days..
It would be interesting to see scheme implemented in hardware, complete with primitives intended to be wired to low-level pointer manipulation functions. Further, it would be interesting to see someone seasoned in low-level C sit down with a copy of Lion's Unix Commentary and the NetBSD sources and attempt to implement a minimal Unix atop the scheme hardware using only said hardware's scheme dialect ("SysScheme"?).
Not sure what you mean by that. I meant exactly what I said: I feel sorry for anyone whose linguistic toolbox is so limited that Javascript is their best option for writing low-level code for manipulating electronic devices. It is hard to imagine a more profound mismatch between the tool and the problem it is supposed to solve.
They're not going to be manipulating low-level devices directly. They're going to be communicating via device drivers from JS. I'll bet $100 the device drivers will all be written in C.
The thing people need to learn about Arduino is that it's not important that it's a microcontroller. It's important that it lets you drive and read electrical signals from a PC environment. This lets people do that. Sure, it's like visiting a gated resort in Jamaica on vacation instead of being on your own, but many people like to feel safe and get things done without having to learn too many new skills.
I think that your "I don't care about languages, I already know js." attitude perfectly describes the problem with many JavaScript programmers.
This sort of proud basking in ignorance is shameful, and should be considered unacceptable.
It is absurd to limit yourself to learning about just one programming language, especially when that language is so rife with flaws, and perhaps the worst widely-used programming language ever.
It is also harmful to create code of any sort when holding such an attitude, even when done as a hobby. It shows a complete lack of care about doing things even remotely correctly.
I have to admit, I'm very disappointed to read a sentence like, "I don't care about languages, I already know js." here.
I don't care about the tools at all, I just want to make things. If I can have something up and running in 5 minutes, great. I might enjoy it enough to dig deeper and learn something more complicated (maybe even a new language!). But if it takes an hour just to hello world, I probably wouldn't bother. These are just toys I might have fun with.
And I do know many other languages, I just don't want to learn a whole new one just so I can play with a new toy. Not everyone needs to be a programmer. Just because someone happens to know js doesn't mean they're interested in being the best programmer in the world.
Just because I enjoy brewing my own cup of coffee once in a while, doesn't mean I need to perfect the art of grinding my own beans by hand and crafting the perfect espresso.
I got into programming by playing with Lego Mindstorms when I was a kid. The building block coding interface was really fun and intuitive. "Oh no," a purist would sneer, "you can't code like that, it's horrible. Here, read this tome on C and microcontroller programming before you start." No thanks. I got to enjoy the end result immediately (making a fun robot), and then from there I could look further into making something more complicated, which ignited my programming journey.
I feel sorry you lack basic understanding of linguistics. Any major programming platform today is too complex for a single individual to understand completely. One can spend his time learning several languages (and the platform they run on) or concentrate on a single language. I'd say it's obvious the second choice leads to higher productivity.
You don't see professional musicians trying to play 10 different instruments on world level. Or olympic athletes competing in 10 disciplines. Or lawyer practising 10 domains. But some programmers like to pretend they have 10 languages in their "linguistic toolbox".
> You don't see professional musicians trying to play 10 different instruments on world level.
Yeah, but a violinist wanting to learn how to play the piano doesn't try to rub the keys with a bow. If you are a Javascript Web Developer, picking up a microcontroller is already going pretty far out of your domain. You might as well learn how to use the tools that were already suited for that task.
It is not obvious to me; in fact I would argue the opposite. Each new language generally has an interesting new idea or two, and learning a new language can expand your conceptual toolbox even if you never write enough code in it to consider yourself a master.
I don't know how I'd count the languages I've used so far, but it is certainly more than ten. I'm not fluent in all of them, but almost every one has taught me something. For the most extreme example, I still can't even read Haskell code, and I've never written a lick of it, but in reading about Haskell I picked up some ideas which have had a profound influence on the way I write code in other languages.
One of the reasons I am not a fan of Javascript is that I didn't learn anything from it. All of its bits were obviously cribbed together in haste from other languages. This is no slight on Brendan Eich, who was given something like two weeks to design it, but it's a shame that the most widely used programming language of all time has to be such a mess.
>You don't see professional musicians trying to play 10 different instruments on world level.
That's funny because most of the full time musicians I know can play 3-6 instruments really really well. Kind of like how most of the full time programmers I know can program in multiple languages really well.
Bullshit, I think it's pretty nice at least as a proof of concept. Although the Electric Imp is more clever design with it's user space VM, but Squirrel is still a bit of a oddity to me...
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 universal constant: the limit, as technology proceeds into the future, of the execution time of "Hello World" is some fixed number. Because as soon as we get better hardware, we invent an even weightier runtime environment to slap on it. ;)