Is "scripting" truly Lua's future?

[Matt Campbell <mattcampbell@...>]

The following quote from the recently published Computerworld interview 
with Roberto caught my attention:

Question:  Where do you envisage Lua's future lying?

Answer:  Scripting. It is a pity that the term "scripting language" is 
becoming a synonym for "dynamic language". A scripting language, as its 
name implies, is a language that is mainly used for scripting. The 
origins of the name are the shell languages that have been used to 
script other programs. Tcl enlarged it for scripting a program, but 
later people started applying the term for languages like Perl or 
Python, which are not scripting languages (in that original meaning) at 
all. They are dynamic languages. For real scripting, Lua is becoming a 
dominant language.

[end of quote]

I agree with Roberto about the abuse of the term "scripting language"; 
that is why in my talk at the Lua Workshop, I only used the term 
"dynamic language".  However, I was shocked at the implication, perhaps 
a misunderstanding on my part, that one should not use Lua as the 
primary implementation language for an application as one would use Perl 
or Python, but instead for scripting an application written primarily in 
C or the like.  Though Roberto's answer made me think for a moment that 
my use of Lua is somehow wrong, My experience has been that given enough 
libraries, Lua is quite good as a primary implementation language. 
Perhaps Roberto is saying that Perl, Python, and the like are better in 
that role, so the best use of Lua is for scripting, the purpose for 
which Lua was originally developed.  However, Lua's minimal core and 
relatively painless C API set Lua apart in my mind.  By combining this 
small core with an appropriate collection of libraries, many of which 
are themselves small, one can use a powerful dynamic language without a 
bloated runtime environment.  This is especially useful for developing 
desktop and "smart client" applications on Windows, where even the .NET 
Framework isn't yet ubiquitous, let alone Python or Ruby.  Still, it's 
more difficult to use Lua in this way than it is with the more 
mainstream dynamic languages, especially if one has to write one's own 
bindings (as I have).  I hope that this will change as more libraries 
and tools (e.g. something like py2exe) become available.  The recent 
interest in Lua for Windows indicates to me that there is growing 
interest in using Lua for more than just scripting.

Matt