With any interpreter or vm you have to factor in the LOC of that technology, so I think your measure is not accurate for calculating the statistical likelihood

With any interpreter or vm you have to factor in the LOC of that technology, so I think your measure is not accurate for calculating the statistical likelihood of defects. Also there is the significant added complexity in things like a JIT and bugs by side-effect, (e.g. the runtime hit by garbage collection sweeps). Admittedly for Lua the increase in size is not so big, what is the compiled interpreted now, like 200kb? In any case, it is certainly longer than the comparable C++ program. I agree with you completely that a more significant factor to correctness is in the "legibility" of the code to the author/maintainer. If you can read Lua better than you can read C++, one should by all means use Lua whenever possible because you will produce fewer defects. I think your point about why the industry focuses on java/c# when it requires the same overhead in code to c++ is exactly why there is a recent "resurgence" in c++ . The whole back to native is a recognition that java (especially j2me) and c#/.NET has failed to deliver on most of its marketing promises. It isn't to say they don't have compelling visions, but in the end they don't offer any more than C++ and you get alot more portability and predictability. Just my $0.02.