JavaScript right on the hardware
technical.io
technical.io
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. ;)
http://www.codinghorror.com/blog/2007/07/the-principle-of-le...
For me, the main challenges always were getting the program onto a chip and wiring everthing so that is does not break or shortcut.
Although I agree with you that Arduino C is simple enough for most microcontroller programs and Javascript is a bit overkill.
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...
http://blog.safaribooksonline.com/2013/07/16/javascript-powe...
> 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.
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.
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.
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.
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.
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.
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.
So they each have their trade offs.
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.
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.
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? :)
But one area where Lua is gaining traction is because it is the only high level language that is integrated with Nginx.
Running your own code inside your front-facing web host was bad when Apache brought in mod_php and is bad now.
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.
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).
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.
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.)
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.
[1] http://www.anvari.org/fortune/Quotations_-_Random/3041_quote...
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.
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.
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.
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.
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.
Once you specialize on using one of them, you'll probably adopt their conventions.
I myself haven't settled yet, too my own dismay. It's not easy.
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.
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.
I made this a while ago, see if you can figure out how it works: http://jsfiddle.net/AXTdj/
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.
foo.prototype = { dothis: function(){}, dothat: function(){}
}
In the beginning I wrote it more like
foo.prototype.dothat = function(){} foo.prototype.dothis = function(){}
Which was a lot more ugly.
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.
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.
The prototype system is less powerful .. - No. Just different.
The language will never have continuations.. - Generators help here. We use them with node --harmony
Scoping. - Fat arrows and block scoping coming in ES6.
These features can be used today in node, by enabling the harmony flag. Otherwise wait until next year.
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.
Continuations seem to be rare among other languages you could choose. Personally I have only seem them in LISP, what else is out there?
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 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.
[1] https://pypi.python.org/pypi/greenlet
[3] http://jim-mcbeath.blogspot.com/2010/08/delimited-continuati...
[4] http://oss.readytalk.com/avian/javadoc/avian/Continuations.h...
[5] http://en.wikipedia.org/wiki/Setcontext
[6] http://lua-users.org/wiki/CoroutinesTutorial
[7] http://docs.julialang.org/en/latest/manual/control-flow/
[8] http://www.boost.org/doc/libs/1_51_0/libs/context/doc/html/c...
That's changed since then: http://docs.racket-lang.org/json/index.html
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 don't use lambdas, so that doesn't carry into how I compare languages.
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.
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?"
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?
It's a shame, would love to see more Smalltalk posts.
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.
what?
JavaScript, TypeScript, and Dart have one.
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.
It very clearly states, 'The golden rule of CoffeeScript is: "It's just JavaScript".'
*hyperbole, please forgive me for being not being completely literal.
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.
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.
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.
As someone that codes since 1986 with a CS degree, I am often dismayed what many "programmers" seem to know nowadays.
Lowering barrier to entry is +EV move, almost always. It multiplies crud but more importantly multiplies the 10% that are worth the crud.
Not sure where you are, but universities in Europe are not like in USA.
In many countries public universities are more renowned than private ones and in some, it is even quite symbolic what you pay per semester.
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.
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.
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.
Uau!? Do such universities exist?
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.
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.
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.
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.
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.
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).
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.
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.
You don't have to use the OO inheritance features in CoffeeScript in order to like it on the whole.
> 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
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.
Whatever language it is I'm glad prototyping devices are coming out at a cost that basically makes them an impulse purchase.
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.
So yes, there are people who like javascript.
And since CoffeeScript compiles to JavaScript you can use it anywhere JS runs...
...and that's what makes it a bad language.
That's why there's a book called "JavaScript: The good parts" :)
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.
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.
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.
- All code automatically reentrant
- Partially data-driven tagged and descriptor-based design
- First commercial implementation of virtual memoryI'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.
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.
I just replied to someone who was saying "what's the point, a BeagleBone Black is so much more powerful".
(sigh)
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
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.
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".
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).
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!
var b = require('bonescript');
var state = 0;
b.pinMode("USR3", 'out');
setInterval(function() {
state = state ? 0 : 1;
b.digitalWrite("USR3", state);
}, 100);
var tessel = require('tessel')
tessel.led(1).blink()
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".
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 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.
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:
http://florin.myip.org/blog/how-make-halloween-creepy-blinki...
See the differences? Horses for courses.
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.
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.
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.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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.
I doubt that. It has M-series ARM microcontroller, Linux is usually used with A-series ARM CPUs.
180mhz ARM Cortex-M3 LPC1830
32mb SDRAM
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.
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 hope I just don't understand your comment.
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.
To each their own, though.
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.
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.
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 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.
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.
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.
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 :)
http://arduino.cc/en/Main/ArduinoYUN
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 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...)
<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>
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'.
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.
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.
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
I just wanted to ask the readers here... anybody notice the sticky tape holding it together in the second picture?
So don't worry, js will not take over...completely.
Oh the possibilities!
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..
long live to the hacker spirit!
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.
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.
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.
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".
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.
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.
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.