Long ago embedded systems were a pain. You programmed eproms with ASM and UV lights were involved. Someday the computorium will be so strong, cheap, and ubiquitous that you can program it with whatever you want. This isn't that day.
I applaud the spirit of what they've done, but that's a shrinkified version of a rack server, not a smartened version of a light-bulb. The Internet of things is more about swarms and emergent behaviors and less about turning everything into a tiny stand-alone version of our datacenter servers.
I get it. And its a start. But its so huge and expensive its like considering the rest of the car an API to a tire.
That's a crap-ton of computer and the sysadmin that goes with it to flip a switch. I don't have a beef with programming the 'net of things in java or lua or even pascal. What I'm saying is that that's way too much computing too far down the stack. The closer we get to the GPIO pin, the less computer, expense, and electrical requirements there should be.
I'm just saying that the thing that should be hitched to the actual GPIO pin ought to look and function more like an RFID tag and less like a mini rack server.
I cannot agree (I mean I do from a pure techie point of view) but last week I got my hands in a Raspberry PI for the first time and knocked up a traffic light demo for a school in Python, with LEDs directly shoved into the ribbon cable.
I have not been so child-like excited for years.
by throwing a wasteful amount of computing power into just turning on a light, we put this in the reach of more and more people.
we could have web servers in assembly language, and it would be more efficient use of computing resources - but that's not been the optimal way and it won't be here either
Interesting perspective, in relation to your "swarms of emergent behaviors" vs. "tiny stand-alone ... servers", are these things mutually exclusive?
Everything involved in moving servers downstream is getting smaller and smaller and less and less expensive. Why not have the end node with as much computing power it needs so that it can control and communicate with swarms, rather than the swarm being controlled by a centralized server.
Its less about the actual amount of computing power at the actuating node and more about how much like a computer we treat it. If we have to sysadmin it like its a full-on server, that's probably already too much. Not picking on javascript in particular, but cramming a web-server-ish stack into a light switch feels like it might be heading in that direction.
Its not really a swarm being "controlled by a central server", its nodes discovering each other and creating a de facto, discoverable api amongst themselves without overt configuration. LivingRoom.Lights.Bright=5 will cause modules you've tossed in your living room to say "hey, I'm a light, I'm in the living room, I should be brightness 5 now!"
The thing is, these lights are actually more complicated than our old-fashioned web servers, because while they too have to communicate with other systems, update their codebases, maintain state, and so on, they also have to do all of that in unforeseen environments, surrounded by unknown services they have to discover and use. Plus they have sensors and whatnot. The sysadmin problems are still there, but now they need to be self-serviced, or at least serviced through some kind of autonomous negotiation with the swarm. If it's not allowed the conceptual bulkiness of an overtly-configured server, I don't see how it could be a self-configured one, which seems much more heavyweight.
A bit more generally, I'm just not sure how a light can be all the things you want it to be without having a pretty complicated stack underneath it. This is a hard problem, and there's going to need to be a bunch of technology in there. Even a common stack of technology. In fact, a web server seems like it would be exactly how you'd want here, because it presents a simple, consistent interface for communication. Generalized interfaces between diverse systems is exactly what HTTP has been so successful at. What are the alternatives and how would they make these devices less computery?
It sort of sounds like your objection is that many web servers aren't simple enough in the sense that they have the complicated configuration APIs which are used by their admins, who want to make really specific human-targeted applications out of generic but wide frameworks built specifically to make that possible. Routing and same-origin policy and access control and extension points and caching and whatnot. Perhaps you're about that, but it's not really a problem with the depth of the stack, and none of that is central to being a web server, or even part of NodeJS.
I think that once you factor in things like battery life, mass production price and complexity, they are.
You can have a swarm of lamp-toggling or temperature-showing things built with two reasonably unpretentious chips and a very simple production process, that allows you to build them cheaply and reliably, and have little enough processing power that you can run them off a small battery.
Throw in the stuff you run Node.js on (of all things...) and it's suddenly not such an unpretentious chip that also ensures running them on battery is out of the question.
A lot of people think hardware design is all about milking the processing power. Part of it is, but there are a lot of things that don't get much exposure because most software developers take them for granted. Battery life (and its cost) is a prime example.
I applaud the spirit of what they've done, but that's a shrinkified version of a rack server, not a smartened version of a light-bulb. The Internet of things is more about swarms and emergent behaviors and less about turning everything into a tiny stand-alone version of our datacenter servers.