4 ms·

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

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.

vsviridov 12y ago
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.
boomlinde 12y ago
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.
skrebbel 12y ago
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?
centizen 12y ago
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.
- kybernetyk 12y 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. Making tech accessible to beginners is a fair point. But I don't really buy the headroom argument: There's always the case to use as few resources as possible when it comes to embedded (the micro controller kind of stuff): Power usage. The less overhead your software stack creates the less power your always on/battery powered device will consume.
  - centizen 12y ago
    For production embedded systems I wholeheartedly agree with you. But for educational platforms, especially those aimed at complete beginners, the trade-off for accessibility could be well worth the excess power consumption.
    - DiThi 12y ago
      Case in point: programming GPIOs with Python in Raspberry Pi. I don't have data but I'd bet it's the most frequent use case after lightweight server and media center.
kybernetyk 12y ago
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.
pinkyand 12y ago
One use case in production i might see for this: 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.
Elizer0x0309 12y ago
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. Do not ever justify having high standards. ;)
PuercoPop 12y ago
We shouldn't conflate the language with the implementation [1] [1]: http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/Langages-Enchasses/Common/Strandh-Tutorial/interpreted-languages.html http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/Langa...
daeken 12y ago
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.
danellis 12y ago
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.

vsviridov 12y ago

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.

boomlinde 12y ago

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.

skrebbel 12y ago

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?

centizen 12y ago

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.

kybernetyk 12y 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. Making tech accessible to beginners is a fair point. But I don't really buy the headroom argument: There's always the case to use as few resources as possible when it comes to embedded (the micro controller kind of stuff): Power usage. The less overhead your software stack creates the less power your always on/battery powered device will consume.
- centizen 12y ago
  For production embedded systems I wholeheartedly agree with you. But for educational platforms, especially those aimed at complete beginners, the trade-off for accessibility could be well worth the excess power consumption.
  - DiThi 12y ago
    Case in point: programming GPIOs with Python in Raspberry Pi. I don't have data but I'd bet it's the most frequent use case after lightweight server and media center.

kybernetyk 12y ago

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.

pinkyand 12y ago

One use case in production i might see for this: 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.

Elizer0x0309 12y ago

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. Do not ever justify having high standards. ;)

PuercoPop 12y ago

We shouldn't conflate the language with the implementation [1] [1]: http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/Langages-Enchasses/Common/Strandh-Tutorial/interpreted-languages.html http://dept-info.labri.u-bordeaux.fr/~strandh/Teaching/Langa...

daeken 12y ago

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.

danellis 12y ago

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.