One common argument to choose Lua is that it has a small footprint. Yeah, that's true, but that's useless. Bummer! When I program, I don't have any resource usage pressure. People who have such pressure are either paranoids or playing in the world of embedded computers. This is also a no more existing conception since quad core processors equiped phones are coming into the market. I'm rather confident that what we used to call embedded devices are just dead and are now plain computers"
How I would savor watching him sit in one of our engineering meetings where we discuss byte and cycle budgets available to subroutines on our network routing layer. And, I'd really like to see what he thinks about our 1 MByte firmware limits, 4 MByte flash footprints....
Ironically, We've only recent had the memory budget to consider LUA.
I use Lua on similarly-sized embedded systems. As a result I get readable code, easily ported (and debugged!) under Linux. It really changed the scope of what we could embed.
The truth is that one should be concerned with how much memory is taken in our world of big-RAM consumer computers, too. To do otherwise is purely egocentric, being a bad citizen: he assumes that his software is the only thing running on that system that needs memory. Of course, this concern needs to be weighed against all the other usual concerns of optimization, but frankly, one should not flagrantly waste memory where it is unnecessary. This is a shared resource, not a limitless supply.
We heard this argument a decade ago with CPU. "The hardware will get faster. Moore's Law, lol." Oops?
That sounds positively luxurious... I recently worked on a project where the microcontroller had 768 bytes of RAM and around 32k flash. The hardware team were really pushing for a slightly cheaper version of the microcontroller with only 512 bytes RAM but as we software folks were feeling pinched even at 768, they got overruled.
This will quickly devolve into the Four Yorkshiremen skit, but...
> I recently worked on a project where the microcontroller had 768 bytes of RAM and around 32k flash.
Luxury! I'm in an entertainment industry startup. Our main product uses an AVR board with 512 bytes of RAM and 8k of flash. Program size optimization for 8k is a significant challenge for us.
We also use an embedded networking device with 8M of flash, which is about the sweet spot for Lua...Perl, Python, and Ruby are all too bloated for this context.
To the author, embedded apparently means "phones." With the rise of Arduino and hardware hacking in general, I think there are more and more opportunities involving development under extreme constraints, not fewer.
> We also use an embedded networking device with 8M of flash, which is about the sweet spot for Lua...Perl, Python, and Ruby are all too bloated for this context.
That sounds plausible. We had a 512k dsPIC (I think that's as big as they come) and considered Lua on it, but it wasn't quite practical.
"Being small is not an excuse
One common argument to choose Lua is that it has a small footprint. Yeah, that's true, but that's useless. Bummer! When I program, I don't have any resource usage pressure. People who have such pressure are either paranoids or playing in the world of embedded computers. This is also a no more existing conception since quad core processors equiped phones are coming into the market. I'm rather confident that what we used to call embedded devices are just dead and are now plain computers"
How I would savor watching him sit in one of our engineering meetings where we discuss byte and cycle budgets available to subroutines on our network routing layer. And, I'd really like to see what he thinks about our 1 MByte firmware limits, 4 MByte flash footprints....
Ironically, We've only recent had the memory budget to consider LUA.