Embedded Lua
No one with any sense would include me in a market research focus group. Things I like are definitely atypical—at least for the general population. I like to think I'm pretty typical for a geek though. But even geeks have some variation. One thing's for sure: I like C. Especially for embedded programs. You've probably noticed I like Forth too, especially when I have to write my own language tools. Beyond C, Forth, and assembler, I rarely have much interest in other languages for general-purpose embedded systems.
Of course, a lot of people do value other languages. There has been a big push lately to drive Java to real time and I have done that too, on occasion. Of course, I do use Java on the desktop when it is appropriate (I've mentioned before that other than the emacs vs vi wars, I'm pretty neutral in most of the computer jihads).
There is a language I've heard of before, but never used, called Lua that is gaining popularity in some circles. It is an interpreted language that is written in ANSI C with portability in mind. It apparently has incremental garbage collection and a “table” system which is more or less a dynamic array like you might find in, say, awk or JavaScript.
Although Lua uses C, it has some decidedly non-C-like features such as nested functions, iterators, closures, and coroutines. You can read more about Lua at http://www.lua.org/pil/ or even try it online (with some canned examples if you like) at http://www.lua.org/cgi-bin/demo. Lua has a reputation as a “'scripting” language, but you'll see that it is plenty powerful.
The reason all this is interesting is there is a project to bring the full Lua language to embedded systems (at http://www.eluaproject.net/). Quoting from that page:
eLua is not a stripped down set of Lua; much on the contrary, it strives to offer the same features as the desktop version of Lua, but complementing them with specific features for embedded use. Besides offering different flavors of the full Lua implementation (like the possibility of choosing between an integer-only and a floating point numbers implementation), a lot of work was and will be done in the direction of making Lua more "embedded-friendly" by augmenting the core language with features that allow lower memory requirements.
Ports exist (as of this writing) for several ARM variants, i386, and AVR32. If it sounds like this only runs on relatively “big iron” you are right. While it sounds simple to port eLua, the authors warn that based on ARM Thumb code you should expect to require at least 256K of program storage and 32K of RAM for a complete eLua image, although you might be able to get by with 128K of program for a “basic image.” They also suggest you really want at least 64K of RAM. You also need a C compiler (like gcc) and newlib, unless you also want to port newlib (although the eLua team claims they will eventually remove the newlib dependency).
I don't think we'll see a port to a PIC16F84 anytime soon. This is not a “mini language,” by any means. And while it is “Forth-like” to have the entire run time system on chip, it isn't very “Forth-like” to need that much memory! Still, as I said, I'm not typical, so I'm sure someone out there wants Lua on a chip.

