Javascript is a good programming language, in that it's expressive, fast (much faster than Python), and more importantly it runs everywhere. No ecosystem can grow without developers, and the success of Node.JS clearly shows that developers like a system they can dive into without much prior effort, using skills they already have.
Tessel allows web developers to use skills they already have to do new things. How could that possibly be a bad thing? Just because Javascript has '==' and '===' and both 'null' and 'undefined' and {} + [] !== [] + {}? I swear, everybody seems to have seen the 'Wat' talk and thinks they're now experts on Javascript development.
Javascript, like many languages (even PHP!) can be written in a 'good' way and a 'bad' way. Thankfully, it's not very hard to write in a good way and it lends itself very well to I/O bound applications like webservers. Embedded devices, depending on the application, could also be very I/O bound, waiting on sensors, cameras, wifi, etc.
Javascript is actually one of the fastest interpreted languages in existence and thousands of new programs are being written in it daily. It's easy enough for a total beginner to use yet powerful enough to port Unreal Engine 3 to it. Get over your biases and recognize that JS brings with it something that Haskell, Scala, etc., will never be able to match: large numbers of ready developers.
It's not the best tool for the job. It's also not the worst tool for the job, and it's an extremely popular language. If it brings more people into the hardware space (which is its expressed goal), it will be a success.
Wait... when did we get to the point where things that were faster than Python were deemed "fast"?!
And of course, "fast" isn't the right term for embedded systems. The right term is "efficient". In embedded terms, Java barely qualifies as passable, let alone Python.
Javascript only has so much room for the bad to hide in--it's a little quirky, but isn't half as open to WTFs as, say, C++ (any generation thereof).
Don't be hating just because these new kids don't have to bang their faces into machine code or shitty C macros--it's great to have a way of trying different programming techniques for embedded systems.
You know, I only know JavaScript about a fraction as well as I know C++, and I can say with a great deal of confidence here... no.
C++ has lots of WTF's in strange little corner cases (mostly around the C compatibility issue). C++11 has done a good job of cutting down WTF's. In JavaScript you needn't go to the corner cases... it's right there in the normal cases.
We're talking about a language that still doesn't have a standard way of reading and writing bytes... for talking to hardware. Think about that for a moment.
> Don't be hating just because these new kids don't have to bang their faces into machine code or shitty C macros--it's great to have a way of trying different programming techniques for embedded systems.
Honestly, I'd not have blinked if the idea was to use Java (even with its lack of unsigned arithmetic), C#, Objective-C, Lua, or even say Go to do the job. I mean, you need to use some kind of a language and you want it to be something that a lot of programmers will find accessible.
But picking JavaScript for this job is kind of like picking Forth to build the new, more accessible database query language...
Wrong. Javascript has typed arrays. When's the last time you actually looked at Javascript? 1998?
"Honestly, I'd not have blinked if the idea was to use Java (even with its lack of unsigned arithmetic), C#, Objective-C, Lua, or even say Go to do the job."
They are using lua. They just have a front end to lua that uses javascript syntax, it would seem. Because languages without curly braces are scary, and the goal is to make this stuff accessible.
To the expert, making your niche accessible to plebes is scary. I understand.
See comments here: https://news.ycombinator.com/item?id=6468339
As recently as a few months ago I had to base64 encode a binary protocol because the JavaScript guys couldn't handle decoding the raw bytes.
> They are using lua.
Yes, but it seems like lua is merely used as a target rather than a programming language. What language people actually code in is highly relevant if your goal is to make a domain more accessible.
> They just have a front end to lua that uses javascript syntax, it would seem. Because languages without curly braces are scary, and the goal is to make this stuff accessible.
There are a lot of languages with curly braces that aren't half as scary as JavaScript.
> To the expert, making your niche accessible to plebes is scary. I understand.
I appreciate your "understanding". Next time you are trying to make the big "I can read your mind" power play, you might want to read the context a bit more carefully.
I don't generally do programming that talks directly to hardware, so even by your rationale I have no reason to be threatened, and I'm all for making this niche more accessible. I've seen excellent jobs of making hardware accessible to novice programmers using Java, Smalltalk, and even things like SCRATCH and Alice. I think that stuff is great. As you put it, "making a niche accessible to the plebes" is a great endeavour and what I have spent most of my career striving for. I've learned a thing or two about that path along the way. This isn't the first time a choice like this has been made. I thought I'd share that this particular choice, if anything, undermines the goal.
but that isn't what you shared. All you had to share was vague old man gripes about a language, with the only concrete example being something that is only really half true.
For christ's sake, you suggested Java and Objective-C for the task. How do you expect to have any credibility after that? For a novice language, why are you expecting a typical task would be decoding a binary protocol?
To claim that you are just sharing your wisdom here is intellectually dishonest.
Because while they might not be considered "hip" languages, they have large developer communities and are comparatively straightforward to pick up for any web developer that isn't familiar with them, yet they still have good support for the task at hand: talking to hardware.
> For a novice language, why are you expecting a typical task would be decoding a binary protocol?
Because they're talking to hardware, and because working with binary is actually much simpler (if your language doesn't have some bizarre aversion to it).
If you've ever taught novices to program, it's actually easier to start with binary as you avoid all the complexity of text encodings and parsing. You want an integer? Read an integer. No length prefixed fields. No reserved characters. No escape sequences. No terminating characters. No character set encodings. No case sensitivity or symbolic equivalents to worry about. The worst you might have to deal with is endianess and usually you can dodge that issue by starting with native endianess. C makes it harder with it's "not sure what width that is" fixed point integers, but that's part of why you don't pick C for that job either.
Working with binary only really becomes a pain once you have to start talking to humans.
compared to javascript. really? you think java is "easy to pick up" ?
I'm going to have to just say I disagree with you there. I don't like my chances of convincing you how silly that sounds. You seem to be operating on some very peculiar assumptions.
Yes, compared to JavaScript, it absolutely is.
Really, the only PITA with learning Java is all the framework-itis (which is starting to become an issue with JavaScript as well, but that's another story...). For things like embedded systems, Java doesn't have any of that stuff and it magically returns to the comparatively simple language for programming network aware hardware it was originally intended to be.
> You seem to be operating on some very peculiar assumptions.
My assumptions are from teaching and watching other teach both children and adults how to program (usually with adults it has been people who are already professional programmers). I'd absolutely agree that Java isn't the best teaching language, but particularly if you've got someone who already knows how to program (which is kind of what I think of when I hear "web developer") at least at some basic level, it tends to be pretty easy to pick up.
JavaScript on the other hand, is quite the opposite.
I've worked with "copy-and-paste" developers who couldn't really write their own program from scratch to save their lives. When you asked them to explain what the code they'd pasted in was doing, JavaScript was invariably the language where they had the hardest time deciphering what was going on, and more often than not, you ended up sympathizing with their difficulty. (C++ and Perl can also be quite difficult to decipher, but they tend to have the advantage that anything much more complex than a one liner generally won't work at all if just blindly copied and pasted, so copy-and-paste coders tend to be rarer breeds there).
You simply can't say the same for Java, C, C++, or assembly--frameworks and the other nonsense notwithstanding.
Tell me, if you were looking to teach people to write Java code for web applications (I know, perish the thought!), would you start them off writing applets?
> You simply can't say the same for Java, C, C++, or assembly--frameworks and the other nonsense notwithstanding.
Oh... I don't know if you can really say that. http://www.javarepl.com/console.html
;-)
Your statement about the ubiquity of JavaScript runtimes is really JavaScript's strongest feature IMHO, but I don't think it is terribly compelling in terms of developer accessibility. You could make something like that argument could say something pretty similar in support of DOS shell, PowerShell, AppleScript, VBScript, VSMacros, XSL, but no one would ever think that a defensible argument for them. Sure you want accessibility, but I think it's okay to suggest that a one click install not be outside the grasp or patience of a developer on their way to writing for distributed device systems... ;-) The difference between "open your browser and now start to learn this language" and "open your browser to download and install this app so you can start learning this language" shouldn't separate anyone who was going to make it in the first place.
I get the point that he doesn't like javascript. Why should anyone care about his personal preferences?
I code in lots of languages besides javascript. I am not insisting on anything. If it were my choice I would have gone with lua, or some dialect of logo or lisp. Or even haskell. it is him insisting that javascript should not be used, with the only justification being something that is not true. Having thoroughly debunked that one piece of evidence he had, what's left? Why should anyone take his opinion seriously?
Resorting to calling me "some kid" is pretty classic though. Did you run out of real things to say, and decided to resort to just dismissing me with ad hominem?
You keep using that word. I do not think it means what you think it means.
> I get the point that he doesn't like javascript.
Actually, that wasn't one of my points.
> Why should anyone care about his personal preferences?
I have no idea.
> it is him insisting that javascript should not be used
Read again. I did not insist that JavaScript should not be used. I said I did not feel it was a good choice. As you pointed out, and I pointed to some obvious signs of why it might not be. My opinion being what it is, that is no basis for insisting upon anything, but even if my opinion was law, the fact that something might not be a good choice is no reason to insist it not be done.
> Having thoroughly debunked that one piece of evidence he had, what's left?
You keep using that word. I do not think it means what you think it means.
> Resorting to calling me "some kid" is pretty classic though. Did you run out of real things to say, and decided to resort to just dismissing me with ad hominem?
Hey, one more dismissal! I think we have a record.
Seriously? You're going there? Did you forget that you bolstered your argument with "old man" just yesterday? One might be concerned about projecting so much...
"Some kid" clearly was directed at me as a person. so..yeah. I'm going there.
No worries. I didn't take it personally, but it was kind of a "what kind of argument is that?" moment.
I generally don't think of FUD as an "old man" argument (more like a "man keeping you down" kind of thing ;-), and not really very applicable to a venerable and pervasive language like JavaScript, though I guess Node is newish (and ironically the JavaScript environment I'm most familiar with).
> "Some kid" clearly was directed at me as a person.
I think if you look carefully at the thread, you'll see that the "old man gripes" comment unfortunately presented you as a petulant child and provoked an anti-ageism response from jbooth, which ultimately ended in the "some kid" comment.
I don't think jbooth was trying to make a technical argument at that point; it was indeed personal, and an empty ad hominem, but you unintentionally opened the door for that. Something to keep in mind when processing his comments.
He didn't seem to grasp why working with streams of bytes is important in this context, and why extremely spotty/inconsistent support for it is not sufficient. If he had a broader base of experience, or if he was inclined to listen to those who have such experience, maybe he'd get it.
Regarding the limits of how far this Lua / javascript combo can or should take us I refer you to the words of Roberto Ierusalimschy, creator of Lua, himself (I agree with him):
> I must confess that I would be very reluctant to board a plane with flight control implemented in Lua or any other dynamic language.
http://lua-users.org/lists/lua-l/2008-10/msg00405.html
I think if the goal is to make little gadgets that put large block letters over jpegs of cats and post those jpegs to social media sites, Tessel's software side is on the right track. It might not be so great for "internet of things" gadgets that interface with the real world, in real time, in novel ways.
(in fairness their hardware looks interesting, though currently overpriced)
Happy?
And of course, C++ isn't exactly a great choice for making hardware programming more accessible. I hear tell that's how a lot of it is done already. ;-)
No. Don't compare the unalduterated failure that Javascript is to the sound reasons behind C++ messiness.
The road to Hell is paved with good intentions.
C++ isn't merely messy--it's a bloated festering gibbering idiot swimming in a fetid pool of infectious waste, the true depth and horror of which is hidden beneath a tapestry of warts and scabs. For the unwary, it seems sound enough, and then a few steps and templates later and the whole rotten structure has given way beneath their feet, plunging them in over their head in offal.
Again, Javascript is a relatively tiny language compared to C++.
I am concerned that many of these products will not hit practical state until issues like power consumption and cost can be addressed. I don't want to have my device wired and I don't want my $1 dollar light bulb to cost $40.
If these guys insist on using JS they should compile it to 8bit code, so that we can better address to cost and power issues. Right now they have something that is larger than an Arduino. My gut reaction is that python might be a better fit.
Using JS for hardware is an audacious, repulsive, brilliant, horrifying idea - maybe people don't want to call it web assembly language, but it's certainly web lingua franca. If you want to execute in the client, you have to use it. If you don't like it, everybody is writing frontends that compile to it (e.g. coffeescript), asm.js to compile it to, and writing books about the "good parts". So... every web developer knows javascript... and assuming it's they who will make the "web of things"... it makes sense to harness all that work and future work around JS (though I'd think the "internet of things" would be made by more hardcore folk, like the TCP/IP designers).
I don't know if this will pay off for them, but kudos for the chutzpah to actually do it (and for even considering it!) But it really could work out - whoa dude, awesome leap of faith!
Javascript is basically Scheme/Self with a C-based syntax[1][2], and both Scheme and Self are well regarded.
It has a bad reputation because of the terrible code people write using it in web browsers, but as languages go, it's pretty nice.
Browser/DOM APIs OTOH are historically pretty awful.
I suspect many of those who think it is terrible do so based n language snobbery, or they cannot separate the language from what it has been used for.
I may well be wrong, though - what actually makes it a bad language in your opinion?
Javascript has first class functions. It has closures. it has nice object/literal syntax. If you don't consider it cheating to use a library, it does have macros if you use sweet.js. It has a metacircular evaluator, from the very beginning called "narcissus", and if it had homoiconicity, it would be even more direly hated than it is now. Having syntax, for better or worse, is a strength that means that people actually use the language. For reals. Not just that one time at college.
The real question is how are any of those features actually useful from anywhere but a theoretical purity standpoint? We're not exactly writing AI systems here. At the end of the day the language is there to write programs. And the sophistication of the programs you need to write in javascript doesn't really need those things most of the time.
But basically, ask anyone with Lisp experience. Only JavaScript people without Lisp experience argue that JavaScript is Lispy.
Most of my recent web development work has been all frontend, with the server-side integration as lightweight and generic as possible and Javascript to do everything else, not so much because that's necessarily an ideal way to do it as because Javascript is so much more expressive, and less painful to work in, than any of the server-side options of which I'm permitted to avail myself -- PHP and Perl, basically, with a strong institutional preference for the former, because apparently being able to pick any of a hundred random idiots off the street and have them write code for you is a benefit? A low barrier to entry is not, in this context, a good thing. (Granted, the same can be said of Javascript, but there's a qualitative difference in that Javascript at least makes it possible to write good code.)
as for your second remark, uh... Douglas Crockford?
What you should take from that assertion is "Javascript is more functional than imperative" (which is correct) and not "Javascript is lispy" (which is not).
[1] http://hop.perl.plover.com
[2] Perl is much more like Lisp than it is like C (from Preface)
[3] ... the book "Paradigms of Artificial Intelligence Programming", by Peter Norvig, includes a section titled "What Makes Lisp Different?" that describes seven features of Lisp. Perl shares six of these features; C shares none of them. These are big, important features, features like first-class functions, dynamic access to the symbol table, and automatic storage management. (also from Preface)
Remember, I was recruited to "do Scheme", which felt like bait and switch in light of the Java deal brewing by the time I joined Netscape. My interest in languages such as Self informed a subversive agenda re: the dumbed down mission to make "Java's kid brother", to have objects without classes. Likewise with first-class functions, which were inspired by Scheme but quite different in JS, especially JS 1.0.[1]
I presume you saw the word basically in my post? There's no doubt it is simplified, but that's a strength as well as a weakness.
But anyway:
A metascircle evaluator: https://github.com/mozilla/narcissus
It's not Homoiconic, and nor does it have macros - but a number of the languages the OP named as "good" languages lack both these features too.
I stand by my point: Javascript is a perfectly good language.
You make it sound like you think having to be smart to use a language is a good thing.
At the same time it's a double edged sword - because it looked so similar to C, it most likely was so successful.
I'm talking historically as someone who was the typical C / Perl programmer back in the 90s when the web took off and made this exact mistake.
You forgot to mention "and without a native way to read and write bytes", which is one of just a few highly relevant examples of why it might not qualify as "a good programming language" for the job. (Others might include having a probabilistic parser...)
Oh, and look here:
http://www.khronos.org/registry/typedarray/specs/latest/
We have an "editor's draft", updated on July 2013, littered with "non-normative" sections, and not on the ECMA site.
You can check out the language standard itself and searching for "typed arrays" there: http://www.ecma-international.org/publications/standards/Ecm...
So yeah... not standard.
Do you think it is maybe possible that a language that had standard ways of working with bytes say within the first decade of popularizing it just might be better suited for talking to hardware?
It is relevant. I'm questioning the wisdom of that design choice.
You have the assumption that "Talking to hardware" necessarily involves dealing directly with binary protocols. And javascript isn't good at that. (though it CAN do it, if pressed)
And you're right on both counts.
I think what you are missing though is that on a product like this, why wouldn't you do the binary protocol stuff in a C module and expose a nice easy api in the scripting language as is the usual practice? In the presentation it very much looks like that is exactly what they do.
You guys have been going at it for a while on this thread. I thought what cbsmith was saying the entire time couldn't have been clearer. I also think your statement here completely concedes his/her point.
You went from calling him/her an "old man" (your words) for not accepting your contention that Javascript can do it all, to advocating the use of C to handle the stuff it doesn't do well.
C. That pretty much says it all.
I never said javascript could do it all. I said that it happens to not be true that javascript doesn't have a native way of dealing with binary. It turns out it does. that's not everything. That's one thing.
It was pretty clear. You just didn't seem to be in learning mode. Your "old man" comment was dismissive on its face and you made assumptions rather than ask thoughtful questions. You said yourself that you understood once you went back and re-read. There wasn't anything new there.
>that's not everything. That's one thing.
It's the thing with regard to that discussion.
I don't buy your depiction of events at all.
From cbsmith's very first post on the thread:
>We're talking about a language that still doesn't have a standard way of reading and writing bytes... for talking to hardware. Think about that for a moment.
You directly took exception to this and even quoted from that part of the post in doing so.
You don't have to "buy" my depiction. Just go back and read (for at least the third time, apparently).
Maybe if you're so concerned about me getting it, you can point out what his actual point is, which you seem to think is so obvious? spell it out for me.
I'd started typing a reply that outlined what just happened, but it would essentially be a strange Cliff's notes recap of the thread. I'm not sure that I want to continue or that it would be sufficient in any case.
So, apparently I'm not as concerned about your getting it as I initially thought I was. Perhaps someone else can jump in here and "spell it out" for you but, as it is, I'm content to leave things where they are.
Good luck.
Keep in mind that he criticised javascript for not having a standard way of reading and writing binary bytes (even though it does) and then suggested lua (which does not, at least not anymore than javascript does). My vague understanding of the point he was trying to make is that since javascript wasn't originally designed to deal with hardware, it's not a good fit. I don't find this to be a compelling argument though. It's more of like, a thesis, with no supporting evidence or premises, and the only point being the binary bytes thing, which is pretty debunked. There's no other point. No detailed analysis about exactly what it is about javascript that he thinks is unsuitable. Just vague handwaving.
Do you have anything to add which might flesh this out? You do know the difference between an argument and a vague complaint right?
No, I didn't criticize JavaScript. I criticized the _choice of JavaScript_ for the task. There's a world of difference there.
> the point he was trying to make is that since javascript wasn't originally designed to deal with hardware, it's not a good fit.
Actually, as I stated that there were a number of factors that pointed to it not being a good fit, and that was just an example of one of them. I'm kind of shocked that a statement like that somehow lead to so much controversy.
> I don't find this to be a compelling argument though.
Cleary.
> It's more of like, a thesis, with no supporting evidence or premises, and the only point being the binary bytes thing, which is pretty debunked.
Yeah, it really, really wasn't a thesis. It was a single point , and not presented as a conclusive point, but as an easily identifiable and understood indicator of a cause for concern.
And I really take issue with the "pretty debunked" characterization. I can't believe you'd say that a feature that over 15 years after it was initially conceived and popularized, after a dozen revisions, nearly a half dozen major revisions, and lord knows how many countless reimplementations, wasn't even consistently implemented on the language's primary platforms, was a byproduct not of the revisions of the core language but rather of another effort to add a specific feature (WebGL), and which you yourself described as being standardized "any year now", is a "standardized" feature of the language.
> There's no other point.
Actually, I made other points. I didn't go in to them in much depth because you seemed unable to accept even the most basic points and didn't offer any counter points (despite me inviting you to).
> There's no other point. No detailed analysis about exactly what it is about javascript that he thinks is unsuitable. Just vague handwaving.
Perhaps I should feel bad about this, given the detailed analysis of precisely what it is about javascript that you think is so suitable. Just a lot of flaming.
> Do you have anything to add which might flesh this out? You do know the difference between an argument and a vague complaint right?
You might want to consider what possible motive I could have at this point for attempting to further explain my point.
In a sense, you are right, there is nothing about javascript that makes it particularly suitable for programming hardware. Nothing at all, for many reasons that you kind of hinted at but, as you say, never really went into in any depth.
The main plus for javascript, is that it's accessible to people who already know javascript, and there's quite a lot of them. The other plus, potentially, is that existing software may be able to run on it. However, as I pointed out in a much much older comment, truly, it's not clear to me really what the use cases for this device are, other than that it's a way to run javascript on hardware, and some people might want that. (as I point out in another more recent comment, if it were my own project I would have chosen differently)
My goal was, initially, to just try to turn the conversation away from language wars toward actually discussing the device. and its merits. I have clearly failed.
What I've been trying to get you to do was, rather than just say "I don't think javascript is suitable", to actually go into some detail about that. over time you revealed that you believe that being able to deal natively with binary protocols is a core feature of a language suited for hardware.
While I concede that this is a late added feature to javascript, it is a core feature of node.js, which is the api this hardware device purports to emulate. node.js is a kind of defacto standard at this point, which is good enough. To my knowledge there are no standards documents for lua, python or ruby and people have no problem using those languages.
So what else is there that gives you the willies? You seem to believe you know something, trying to impart some knowledge you have, but I can't get at what it is, because you may have assumed you said all kinds of things you haven't actually said. (such as, the assumption that I needed to intuit, about binary protocols)
Good on you. I was hopefully that if we rode it out, eventually we'd somehow uncross the Rubicon. Good on you for doing so. Thanks.
> The main plus for javascript, is that it's accessible to people who already know javascript, and there's quite a lot of them.
For this particular context, I couldn't agree more. The one caveat I'd put on that is that a not insignificant quantity of those people who already "know" JavaScript don't really "know" it; they could probably be fooled for a disturbing length of time if they were swapped over to Java (and that's not to say the languages are really that similar). Still, people with at least passing familiarity with JavaScript are numerous.
> The other plus, potentially, is that existing software may be able to run on it.
Yeah, that one I'm not buying much. I can't think of any other top10 development language that wouldn't have a richer software ecosystem for this problem domain. Even for the more general server-side development, the Node software library is growing fast, but it is very, very thin and represents a tiny fraction of the JavaScript software world.
> it's not clear to me really what the use cases for this device are, other than that it's a way to run javascript on hardware, and some people might want that.
Yeah, and even from that context, if you went with a JVM runtime, you'd have JavaScript (admittedly not quite as nice as with V8, but still enough for most people who'd want to play around with an embedded JavaScript server) along with a plethora of other languages to choose from, which I'd have to think would do a much better job of getting a broader selection of web developers started in the "Internet of Things" paradigm.
> My goal was, initially, to just try to turn the conversation away from language wars toward actually discussing the device. and its merits. I have clearly failed.
Hehe. Well, responding to questions about the language choice can do that. ;-)
That said, I will ask that question: there are lots of other efforts to package up Cortex-M microservers for sensornets and ad-hoc devicenets and bundle them with user-friendly API's. I haven't been able to discern what's particularly exciting about this approach. What do you think is uniquely interesting about this solution?
> over time you revealed that you believe that being able to deal natively with binary protocols is a core feature of a language suited for hardware.
"core feature" means different things to different people. I look at it as a building block that a lot of core functionality for working with devices tends to build on top of, and a very important tool to have in your back pocket when dealing with a legacy device with lord only knows what fun little protocol bugs^H^H^H^Hquirks. It's not that you have to have it, but not having it tends to discourage the rich development of that larger ecosystem, and in JavaScript's case I've had first hand experience with it.
> it is a core feature of node.js, which is the api this hardware device purports to emulate. node.js is a kind of defacto standard at this point, which is good enough.
Agreed. My main problem is "good enough" is not exactly the kind of quality that makes me say, "oh yeah, we obviously should choose this one". If someone hands me a Node.js server and says, "talk to this air pressure sensor", I'm not going to say, "it can't be done" because obviously it can be done, and without having to move mountains. But if I'd not been handed anything other problem of talking to the air pressure sensor, even if I was looking to bring on a ton of web developers with little or no familiarity working with hardware, Node.js wouldn't exactly have sprung to the top of my mind. ;-)
> To my knowledge there are no standards documents for lua, python or ruby and people have no problem using those languages.
There are no EMCA-like standards bodies for those languages, but there are documents defining the language (though Ruby in particular seems to have a bit of the, "however the runtime works" mentality it is still shrugging off). That actually has been an impediment from time to time, though obviously not a huge one.
Lua's language is quite detailed about bindings to the native platform and even has a specific type, "userdata" for unmanaged blobs of memory, and Lua's deceptively named "string" type holds an 8-bit clean arbitrary set of random bytes, so not only are its "string functions" and IO libraries naturally capable of byte-oriented processing, there's little friction for even ancillary libraries supporting and exploiting it. Ruby's string implementation is similar.
Python has, as far back as I can recall, had support for binary IO and processing, though I'd qualify that by saying it has been somewhat hokey, though things like structs and Cython have helped mitigate it. Until 2.7.x and 3.x.x came around, I'd give Python demerits in this area, though not as bad as JavaScript.
> So what else is there that gives you the willies?
As I mentioned, there's the probabilistic parser. When you are learning it is nice to have forgiveness, but it is much better to have each and every mistake pointed out to you. A probabilistic parser makes things less transparent. That can be worth it if you're going with a "do what you can" mentality that makes perfect sense for web documents, but with hardware imprecise communications are just as wrong as incorrect ones. This doesn't mean a language need be hard, it just means that you want to be painfully clear about what is and isn't correct from day one.
Then there's JavaScript's bizarre and limited approach to arithmetic. Java's lack of unsigned fixed point arithmetic has drawn some deserved criticism, but those concerns seem puny when compared to JavaScript's quantum numbers that exhibit double/int32 duality. Not a good can of worms to open up, particularly when talking to hardware that might (per Murphy: read will) have odd numerical representations of its own. Even if you assume numbers are passing back and forth as decimal arithmetic strings, that's a Pandora's Box of fun just waiting to be opened that isn't going to make the experience any easier even for programmers fairly familiar with JavaScript.
Then there's the whole async I/O, event driven callback model. While I personally love that model, and at first glance it seems like it'd be a perfect match for sensors and devicenets, it does come with some downsides. It's a less natural paradigm for a lot of more novice programmers, and the way it decouples logic and injects layers of indirection in to the code can lead to confused developers when tackling new paradigms. Coroutines seem to present an initially more accessible approach to that model, and the thread model is initially often much more approachable for developers (though the popularity of Java NIO is an obvious testament to advantages of getting comfortable with I/O state machines sooner rather than later).
So there's some more straight forward concerns. Again, not the "it can't do X" variety, but more the "we're trying to get a fish to climb a tree" variety, is this really the best way to get to the coconuts?
"I haven't been able to discern what's particularly exciting about this approach. What do you think is uniquely interesting about this solution?"
It remains to be seen if it's uniquely interesting. If it is uniquely interesting, it will be because of node.js's supposed ability to do well with distributed server type things.
It is my general opinion that node.JS gets overused for quite a lot of things that it has no business being used for. But one thing I would use it for is the high concurrency, small payload size stuff like instant messaging and MMORPG's.
Imagining a robotics scenario, you could enable a simulated version of a swarm of robots that runs in a webpage.
with distributed sensors, you could integrate it with a web server set up using the same language- the sensors look just like some extra nodes in the distributed network. That could be nice.
The nice thing about javascript of course is that, all though it is kind of dumb out of the box, it is expressive enough that you can build some useful abstractions- and manage the callback hell that people tend to run into with node.js coded naively.
On the other hand it may well be making a fish climb a tree. Low level hardware stuff was never javascript's strength. What could be interesting though is the higher level event driven stuff which is harder to achieve with things like c/java/arduino
For almost anything that runs in a web page, JavaScript is a better option. ;-)
> The nice thing about javascript of course is that, all though it is kind of dumb out of the box, it is expressive enough that you can build some useful abstractions- and manage the callback hell that people tend to run into with node.js coded naively.
Yeah, no question that binding to JavaScript is it is very expressive. In terms of intrinsic language properties, its hard to be both really expressive and a good language for learning. Some really beautiful languages manage to thread the needle, but I don't think JavaScript is one of them. Still, it is a tempting choice to introduce people to simply because of its ubiquity...
> What could be interesting though is the higher level event driven stuff which is harder to achieve with things like c/java/arduino
FYI, Java can actually do that kind of thing even better than JavaScript: http://vertx.io/
The comments were not intended to be dismissive about the language; I'm kind of surprised that statements with qualifiers like "might" would be interpreted as being "dismissive". Perhaps you didn't notice them?
If you look at my comments, while I was pretty strident about the facts, I took great pains to extensively qualify my opinion. To illustrate, I'll quote from my initial comments to you with highlights to draw your attention to the qualifiers:
> ...it might not qualify as "a good programming language" for the job...
> ... Do you think it is maybe possible that a language that had standard... just might be better suited for talking to hardware?...
> ... Maybe JavaScript makes working with hardware more accessible than other choices, but I doubt it...
Now, no question I was expressing a difference of opinion, but I think if I had said any more times and ways that my critique wasn't of the language in general, but of its suitability for the task in particular, I'd have felt like a broken record. Not only wasn't I dismissive of the language in general, but I wasn't even dismissive of the application of the language for the problem in particular. I expressed that I didn't think it was a good idea, but I explained my basis for the opinion and qualified it extensively, to the point of stating that I could be wrong even if I didn't think so.
I honestly can't explain your characterization of my comments other than speculating that perhaps you came in to the discussion already wearing your language advocacy hat, and that framed & distorted your perception of the discussion.
This is kind of obvious, but given the context I think it might be necessary to say it anyway.
Perfectly good programming languages tend to have strengths, weaknesses, and areas of focus (it's an inevitable consequence of both language design and Darwinian forces that dominate the marketplace of ideas). I don't think any of the flaws I pointed towards are necessarily bad points about the language and in certain domains are actually great strengths (probabilistic parsers are a great idea for web content).
> it only finally slipped out of him almost by accident what he was actually trying to get at, and even that isn't much of a relevant point.
I think a better way of describing it is that it "finally slipped in to you". ;-) When something is said multiple times in different ways, that's not "slipping out".
Obviously, you didn't understand what I was communicating, and no doubt this is partly a reflection on my own failings to communicate effectively. I apologize for not doing better.
However, you might want to consider the possibility that particularly given the limitations of the medium, the nature of communication failures, and that my point was deemed clear as day by at least one other 3rd party... you may have missed something.
Maybe we can learn something from this experience.
squints
Have you been going back and editing/reediting your comments?
It may account for (some of but not all) of the things I missed from you.
I didn't alter anything that substantively altered or added to the meaning of what I said (when I have done that in the past I have marked the relevant text as an UPDATE so that the change gets noticed by anyone who may have already replied, but that wasn't necessary in this case), and I didn't edit anything any time after (or shortly before) you posted a reply. I find once a comment has been up long enough for people to read it, even in place corrections of gibberish to English increases confusion more than it decreases it.
If you saw an earlier version of an edited post you might have found a non-sensical phrase or two (e.g. I do recall one post where I fixed an accidental "maybe maybe" to just "maybe", I do remember my first post had something like "which just the many of few examlpes" and I'm sure there was one or two superfluous apostrophes in some of the comments which I later removed), then it's conceivable you read something that was later edited, but if it was fully legible (more like, as legible as it is now ;-), then definitely nothing was edited. I can assure you that the qualifiers were there in the original postings.
Truth is HackerNews locks down comments pretty fast, so by the time I might want to change/add/remove to what I've said in a way that even subtly changes the meaning, it's way, way too late for an in place edit.
UPDATE: Murphy's Law strikes again. I remember one edit I did do that might be deemed more significant than the others I mentioned. In the original post where I said, "..it is maybe possible that a language that had standard ways of working with bytes say within the first decade of popularizing it just might be better suited for talking to hardware", I had original used underbar instead of asterisks to emphasize certain words. Once I hit post my mistake became obvious and I went back and fixed it. I made the same mistake again when I wrote the comment where I was quoting myself with previous excepts (so I changed "with italics" to "with highlights" and then promptly fixed the rest of it so that "with italics" was if anything finally the more accurate phrase ;-).
I wouldn't say that it necessarily involves dealing directly with binary protocols, but the issue tends to come up. Particularly when talking with hardware that can't just easily be upgraded, you often find that even "text" based protocols might require some manipulation at the byte level in order to decode them successfully.
But really, the binary protocol aspect was just a really obvious and simple example of the larger "square peg, round hole" aspect of using JavaScript for the task. Maybe JavaScript makes working with hardware more accessible than other choices, but I doubt it.
> why wouldn't you do the binary protocol stuff in a C module and expose a nice easy api in the scripting language as is the usual practice?
I'd argue once you've done that, you're done. The hard part about the "internet of things" is that devices generally don't have a nice clean API's, and that's what needs to change.
Once you have a nice API, you can embed a JVM in their quite cheaply and then support almost any language web developers might want (including JavaScript), and quite cheaply and efficiently at that. Better still, just do a simple REST-ful interface and leave it to the developer to do whatever they want.
Assuming they implement typed arrays in their implementation then your criticism goes away doesn't it?
The point is the language has evolved for quite a long time in a direction very different from talking to hardware. Basic capabilities like the ability to work with bytes are a foundation that a lot of other constructs are built on top of, and adding it in late in the game doesn't undo all that came before it, or provide all that should be built on top of it.
It's not that you can't do this kind of work with JavaScript (obviously you can). It's just that it seems like very bad fit (even if you ignore its history with browsers), when there were a lot of other choices that seem like they'd have made things easier for programmers getting started in this area.
shudder
Javascript is not a choice for many web-devs and for all front-end devs, that's basically the only thing you can use in a browser. And even if one uses a transpiler, 3rd party scripts are still in JS. That's why the hate. Otherwise people would not give a damn about wether it is good or bad. When one is used to something better (like Scala), one doesnt want to spend its time in this poor ecosystem.
DOM apis are quite good ,that's the only reason why most people are using JS today. They are just still inconsistent between browsers.
That is an absolutely absurd claim. Javascript shares similarities to smalltalk, perhaps you confused it with scheme?
I shouldn't have said this, but it's not a very inappropriate response to your comment.
JS sure has its warts. But it isn't really that hard to know what to avoid. Once you do that, it is expressive enough to write apps without sacrificing productivity. It has all the basics you'd need; higher-order functions, closures, decent performance etc. The big win though, is that it is the only truly cross-platform language available today.
The major difficulty today (on the server-side) is that JS has no language support for handling callback interspersed code. This will be mostly resolved in ES6, due next year. We use ES6 features today, via flags.
I also have no problem with a Javascript Kiddie programming my oven in Javascript. AS LONG AS HE/SHE COULD HAVE ALSO DONE IT IN SCALA/OCAML/CLOJURE/HASKELL.
What are you getting at with that?
Really.
Someone has spent a lot of time trying to innovate. This is all you have to contribute?
It's not about bandwidth. It's about latency.
No one is even suggesting that Node is a suitable substrate on which to build, for example, a flight control system, and reduction to absurdity does nothing to improve your argument.
No one except parent.
I don't want to come off as a spoil sport, but can you please edit your comment into something insightful and/or constructive?
As for myself, I will spin this into a question: What existing javascript library or program would most likely benefit from being able to run on this device? Is it just appealing to web devs? the presentation doesn't really get into what compelling use cases this device enables.
Scala (http://www.scala-lang.org/) Clojure (http://clojure.org/) Haskell (http://www.haskell.org/) OCaml (http://caml.inria.fr/)
As much as I dislike it, sometimes PHP is "the right language".
Purity doesn't mean moral superiority (although it sounds like) purity means referential purity for example, where the function when called no matter how many times with the same argument returns the same result. That is beautiful because it allows for interesting compiler optimizations, good for testing. Other looser explanations of purity are -- confinement of mutable state (this could mean monads in Haskell modifications to shared global state), immutable data structures in Erlang or Clojure.
Now that said these are all tools. As I mentioned, in practice, a lot of these people in their day job will end up using Java or C++. But the fact that they decided and managed to learn a new paradigm is what is the key.
Heck it could have been data-flow programming or logic programming (Prolog is awesome too, especially when mixed with constraint satisfaction).
Yet another way of putting it, familiarity with these things point to a level of passion and sets someone apart, that is quite desirable. Now, yes, there is a self-referential quality to it all, the more we think functional programming is a proxy for developer quality, the more people will do tutorials just to put it on their resume. Well, then the next fashion will be something else -- quantum algorithms perhaps, who knows.
1) I'm guessing (by reading between the lines) that you also haven't "been on the job market", and haven't been plausibly tempted to "jump ship" to any language-purist position?
2) <cynical mode> Just because you haven't set up LinkedIn/FaceBook/Google+ profiles yourself, that doesn't mean they don't all have "shadow profiles" for you based of the social-graphs they've got where your colleagues/friends have "leaked" information about your existence to them and enabled them to infer skills/abilities from them… I don't _know_ that they sell data from "shadow profiles" to recruiters, but I do suspect there's enough money in tech recruitment to make it likely…
Single threaded. Concurrency via processes, impossible to share state. And, among the more efficient dynamic languages out there now due to the browser performance race.
Which language doesn't have these options? This could be a description of Bash.
There's a slippery word if ever I saw one. Does Java count? Python? C? You could make arguments for all, or none, of these depending on what "proper" is.
It's practically C and everybody likes C!
Actually, they are compiling to Lua bytecode in this case.
> JS syntax is quite good for I/O
And you can pass around blocks in Ruby.
Once upon a time Javascript was this fragmented language, mostly associated with blinking effects, pop-ups and lame attempts to protect a web page from being viewed as pure HTML. After years of misery the community was tired of how things was and said, "No more"! And so html-tables and javascript was sent to a zip-drive (you probably won't remember those, think of it like a SD-card) to never be seen on the web again.
But evil people who sold out to the dark forces was destined to bring javascript back. By making frameworks they masked the incompatibilities of the language, making it seem like a friend. And the young people who never fought the war, they welcomed this new technology with open arms.
But seriously, we took a typesetting language made for writing documents (just like word) and turn it into a technology for making software. It turned out into a total mess, and now you wonder why taking a language made for manipulating the DOM and using it for manipulating the stack is a bad idea? "When all you have is a hammer..."?
Thad was a tipping point for the web, and the world now is different just because of that.
If you have to choose between power and easiness of development, most people will choose the later, and if I can try a new hardware board that doesn't force me to learn anything new, I'd probably try it.
A lot of people are building awesome things with it. JS haters used to say that it was because it was the only choice for the web browser, but now we see more awesome stuff outside the browser: on the server with node.js, for windows apps, and now on embedded devices.
Seriously, a language that allows you to write awesome things could not be such a bad language. Ranting about people using a language that's not your favourite is a waste of energy.
I code Javascript only because I have to, but its a miserable language.
The same could be said of Visual Basic. I still wouldn't want my thermostat running VB.
"Another major advantage of Javascript is that it is continuously optimized in the ongoing race for performance in the browser"
In an embedded system like this, what you want is something continuously optimized to be bug free and work without fail, not something optimized to be mostly ephemeral and need to work in an environment where if you leak memory for 45 days, people rarely notice.
Browser performance is also not optimized for anything that matches the application workload of this kind of device.
Anyone who tries to bring a product to market with this will presumably be crushed by those who can use less expensive components from better optimized code. At scale, even a few pennies per unit can make a huge difference in your profitability. It seems quite unlikely, for at least the foreseeable future, where you will buy an off-the-shelf thermostat with one of these inside - or anything else running Javascript for that matter - simply due to component costs, if nothing else.
But if you are a web developer who wants to hook up a light that flashes when someone visits your web page, something like this might be a reasonable choice. Being able to build something that works reasonably well with minimal effort is appealing. Who cares if it adds $30 to your BOM and maybe doesn't work every single time?
Personally, this is probably not a device I would be interested in. Playing with embedded systems at a low level is what makes it fun for me, but not everyone wants to learn C and assembly just to throw together a project in their spare time. I think this could be a pretty great product for that certain niche.
You mean like this [1]? These guys have been around for years. How do you know your microwave doesn't already use one of those?
[1] http://www.basicstamp.com/catalog/microcontrollers/basic-sta...
I mean more like what they are using, which is a very young, heavyweight runtime not even meant or really tested for the purpose they use it for.
Look, just because you can make something "easier to program" doesn't actually make it "easier to make work".
Besides, you can choose sensible things. if you need something stable you stay on a known stable version of node (which has it's own issues of course).