A nice introduction:
Looks like ruby2C has been abandoned (Activity Percentile: 0%), which is a shame. High level languages that compile down to C are such a powerful idea, but it's a concept that doesn't seem to get that much attention and traction (developers seem to have given up to either low level languages like C/C++ or higher level languages that limit the portability of their code). The strongest project I'm aware of is ooc , which was created and is (currently slowly) developed by some really clever folks, but it could really use some more love.
Why, you ask? Recall if you will that most ATmega chips, for example, run at 8MHz. Also recall that the Intel 8088 (the brain of the IBM PC) peaks at 10MHz - AND it's 16 bit.
It's such a shame that the current embedded systems crowd keeps beating this dead horse. Performance is not the only metric by which to quantify the performance of a system.
Any engineer worth his salt knows that everything is a trade-off, and there are many, many projects where embedding an interpreter is a good choice. It can buy you things like design agility, memory safety (robustness, security), run-time linking (remote code updates), garbage collection (robustness), green threads (maintainability due to separation of concerns, memory-efficient if done correctly)
In terms of cost, an interpreting JVM will typically be 20x-100x slower than equivalent C code depending on the application (although technically C doesn't do automatic bounds checking and isn't type safe, so it's not really equivalent). Garbage collection often introduces pause times as embedded GC tends to be less complicated than server-grade, but you can still implement time-critical stuff in C. For example, the .NET/TinyCLR based Fez Panda board has no problems doing one-wire because of this. Finally, you tend to be less memory efficient because your high-level language might be OO, doesn't know about bytes/shorts/ints but rather just has the type 'Number', and because of GC.
If you blindly follow the 'performance is everything' mantra, you forget that there is a whole slew of applications where you really don't need 20MHz, and where things like robustness and security are way more important than real-time. The few extra K of memory for the micro might cost you a couple of extra cents, but it can save you a lot of development time. Depending on the volume this might be an appropriate choice.
Normally I wouldn't care in the slightest what language you use, but I guess you could say I am nervous that interpreted languages would be favoured due to popularity and familiarity rather than sound design decisions, and rapidly take over the embedded market.
As for features, the chip in the panda costs $13.44 in single quantities, and $8.13 in volume. An Atmega1281 costs $13.12 in single quantities, and $7.32 in volume. I can see how having a .NET runtime built into your chip with a class library to drive all your peripherals is worth a few extra cents.
> Normally I wouldn't care in the slightest what language you use, but I guess you could say I am nervous that interpreted languages would be favoured due to popularity and familiarity rather than sound design decisions, and rapidly take over the embedded market.
Memory is the bigger issue, the most popular Arduino variant has 2K of RAM and under 32K of program memory. I wouldn't be surprised if the implementations of Ruby's library functions and data structures (array, hash, etc.) eat up most of it.
Edit: "Do you run the Arduino development tool chain on an obscure (i.e., non-OS X) platform?" is a gratuitously condescending in my opinion. Since when's OS X the default/most popular/whatever platform for doing GCC development?
That said -- this is pretty much unimaginable for my current embedded development projects, where C compiler tricks have been the name of the game for some time now. Add a feature, exceed the 8K program memory limit, find something to optimize, repeat. Injecting a Ruby-to-C compiler into this loop would be madness.
Dare I ask if a Python version will become available?
Similar idea, although the VM in this case runs on the micro. Last I looked Arduinos had not enough RAM, but some similar boards like Teensy++ did (I actually contributed a proof-of-concept Teensy++ port.) However since then apparently lots of RAM-size optimisations have been added.