This is awful. What has happened to choosing your language appropriate for the task at hand? If you are targeting embedded platforms, you should not be writing in an interpreted language.
Edit: I was having a bad day, and this comment was over the top. I don't like the current trend of everything should be implemented in JavaScript, but respect what Espruino are trying to do.
Emotions aside, you are 100% correct. The current trend of catering to "easiness" is introducing a slew of cons ranging from bad practices, to just down right stupid engineering.
Look, I get that the recent sea of -duino devices can get annoying and represents a new, unknown genre of programming to you, but don't be ridiculous. What stopping you from using whatever language you want to use on whatever platform you want to? And who are you to define what paradigms should be allowed on which hardware?
Embedded platforms are evolving at an incredible pace, in some cases outperforming PC's from just a few generations ago. There is more than enough headroom to make interpretation a viable model for micro controllers, and there is hardly a better way to make the technology more accessible to beginners. Granted, JavaScript would not be my choice either - but to say that interpreted languages aren't an option is ridiculous.
This gives access to embedded to a very large prospect audience. The good ones will quickly realize the limitations and move on to C and the like... So it's quite great, really. And if you don't like it personally - don't buy it.
I've been writing assembly and C since grade school, but yet this is immediately interesting to me. Rapid development of quick hacks is super useful both in my personal projects and when I'm doing embedded security testing. Would I use this for a mass-market project? Maybe not. But I'll certainly use RAD tools for embedded work for one-offs.
1. Using callbacks as commonly done in javascript, might offer a very easy to use way to write low power code(because the chip can automatically sleep between callbacks). This is nice versus today's high complexity low power design.
2. The author used regular mcu for this board. But low-power mcu needs orders of magnitude less power. And of course low-power pcb design can save even more.
Combining the 2 together, maybe we can see a good enough option for building 1st version, low-power products(say kickstarter guys) where they can spend a bit more on chips and there's less competition on specs - but things like low cost of development, time to market, and high domain knowledge with less technical knowledge are important qualities.
I understand the sentiment. There does seem to be a trend of pandering to web developers in a way that discourages them from leaving their comfortable JavaScript bubble. I'm not sure what that says about developers or the future of the industry, but I do find it a little bit sad.
I agree about language lock-in, but you should definitely write your embedded application in whatever language best fits the requirements, even if this means using an interpreted language. Not all embedded applications are dependent on real-time functionality or low power usage, and using a particular language may affect development time significantly.
EDIT: I also need to stress that "embedded" doesn't imply that a system is particularly limited in resources.
Nonsense. Also, I find your dismissive attitude appalling.
This is not for mass production, or for productization. This is for playing "Jingle Bells" and then sending a tweet whenever someone rings your doorbell.
It enables people who happen to be comfortable in JS most to do some accessible electro hacking. Seriously, how is that awful?
Are you also going to complain that Lego Mindstorms is awful because people shouldn't make industrial robots with it?
People are lazy. People don't want to learn new things and/or leave their comfort zone. The makers of the Espurino realized this and are exploiting it to market their product. All power to them for the good market research.
And as long as I am not forced to use JavaScript I don't really care if people use it to do things that it wasn't intended to do in the first place.
I'm the guy behind this - I just woke up so I'm a bit late to the party :)
It's really good to see a decent discussion here...
For me, it's about getting the right tool for the job. I'm mainly a C programmer, but if I want to manipulate a bunch of files I probably won't use C, I'll use Bash.
In the same way there are (a lot of) times when what you actually want to do with hardware is quite simple, but you'd end up writing a whole bunch of C code to accomplish it - and that's where Espruino will not only be faster, but a lot more fun :)
Someone also mentioned power consumption/events and I thought I'd give you some figures. When Espruino sleeps between events (which is does automatically) it draws ~50uA. Even with explicit power management calls, pretty much all Arduino boards draw at least 5mA (so 100 times more), and without explicit calls it'll be 20-30mA. Raspberry Pi is anywhere from 100-500mA, so over 2000 times more power.
Wow another STM32F design win. Amazing that folks are still using AVR parts when 32 Bit Cortex M parts are cheaper, faster, and more capable.
The trend to on board interpreters is interesting. The whole JS thing with Beaglebones was my first experience with it. Back in the stoneage there were Handiboards with a version of C that was interpreted on the board. And I've built over a dozen robots with boards that ran BASIC of one flavor or another. Personally if you're going with the STM32 chips anyway I expect Micropython is a better starting point.
i don't quite understand, is this for arduino and raspberry pi? I understand comment 1 that the language may not be correct for the platform, but it doesn't come right out and say whether this is for RasPi and/or Arduino although it would appear so since it as -uino in the name. I see they are offering their own board, is this a language and board, neither both or separate? Kinda super confused here.
It really isn't all that special or complicated. The biggest riff (that I have seen) which gives it a bad reputation is browsers coming up with their own conflicting or awkward APIs. (which is one reason why jQuery exists)
[+] [-] alexchamberlain|11 years ago|reply
Edit: I was having a bad day, and this comment was over the top. I don't like the current trend of everything should be implemented in JavaScript, but respect what Espruino are trying to do.
[+] [-] Elizer0x0309|11 years ago|reply
Do not ever justify having high standards. ;)
[+] [-] centizen|11 years ago|reply
Embedded platforms are evolving at an incredible pace, in some cases outperforming PC's from just a few generations ago. There is more than enough headroom to make interpretation a viable model for micro controllers, and there is hardly a better way to make the technology more accessible to beginners. Granted, JavaScript would not be my choice either - but to say that interpreted languages aren't an option is ridiculous.
[+] [-] vsviridov|11 years ago|reply
[+] [-] daeken|11 years ago|reply
[+] [-] PuercoPop|11 years ago|reply
[1]: http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/Langa...
[+] [-] pinkyand|11 years ago|reply
1. Using callbacks as commonly done in javascript, might offer a very easy to use way to write low power code(because the chip can automatically sleep between callbacks). This is nice versus today's high complexity low power design.
2. The author used regular mcu for this board. But low-power mcu needs orders of magnitude less power. And of course low-power pcb design can save even more.
Combining the 2 together, maybe we can see a good enough option for building 1st version, low-power products(say kickstarter guys) where they can spend a bit more on chips and there's less competition on specs - but things like low cost of development, time to market, and high domain knowledge with less technical knowledge are important qualities.
[+] [-] danellis|11 years ago|reply
[+] [-] boomlinde|11 years ago|reply
EDIT: I also need to stress that "embedded" doesn't imply that a system is particularly limited in resources.
[+] [-] skrebbel|11 years ago|reply
This is not for mass production, or for productization. This is for playing "Jingle Bells" and then sending a tweet whenever someone rings your doorbell.
It enables people who happen to be comfortable in JS most to do some accessible electro hacking. Seriously, how is that awful?
Are you also going to complain that Lego Mindstorms is awful because people shouldn't make industrial robots with it?
[+] [-] kybernetyk|11 years ago|reply
And as long as I am not forced to use JavaScript I don't really care if people use it to do things that it wasn't intended to do in the first place.
[+] [-] gfwilliams|11 years ago|reply
It's really good to see a decent discussion here...
For me, it's about getting the right tool for the job. I'm mainly a C programmer, but if I want to manipulate a bunch of files I probably won't use C, I'll use Bash.
In the same way there are (a lot of) times when what you actually want to do with hardware is quite simple, but you'd end up writing a whole bunch of C code to accomplish it - and that's where Espruino will not only be faster, but a lot more fun :)
Someone also mentioned power consumption/events and I thought I'd give you some figures. When Espruino sleeps between events (which is does automatically) it draws ~50uA. Even with explicit power management calls, pretty much all Arduino boards draw at least 5mA (so 100 times more), and without explicit calls it'll be 20-30mA. Raspberry Pi is anywhere from 100-500mA, so over 2000 times more power.
[+] [-] ChuckMcM|11 years ago|reply
The trend to on board interpreters is interesting. The whole JS thing with Beaglebones was my first experience with it. Back in the stoneage there were Handiboards with a version of C that was interpreted on the board. And I've built over a dozen robots with boards that ran BASIC of one flavor or another. Personally if you're going with the STM32 chips anyway I expect Micropython is a better starting point.
[+] [-] Mister_Snuggles|11 years ago|reply
The amount of computing power that's now available in embedded systems is just amazing.
[+] [-] greyfox|11 years ago|reply
[+] [-] kelvin0|11 years ago|reply
[+] [-] kelvin0|11 years ago|reply
[+] [-] revelation|11 years ago|reply
[+] [-] philwise|11 years ago|reply
[+] [-] vsviridov|11 years ago|reply
[+] [-] ErikRogneby|11 years ago|reply
[+] [-] snoopybbt|11 years ago|reply
[+] [-] cordite|11 years ago|reply
[+] [-] codehero|11 years ago|reply
[+] [-] tomphoolery|11 years ago|reply
[+] [-] oso2k|11 years ago|reply