Re: Is "scripting" truly Lua's future?

["Steve Donovan" <steve.j.donovan@...>]

'Scripting' is a great word, but carries prejudice;  something 
'lightweight', suitable for the quick jobs, not for the big workhorses which 
keep our civilization from falling apart.  Or, something that one of these 
workhorses would add, as an afterthought, as 'end user customization'.

A very influential person in this debate was Osterhout (the Tcl man) who saw 
the need for a 'glue language' to tie C modules together.  And this worked 
very well, despite the many weakness of tcl/tk (hint: Bash on steriods does 
not scale.)  As it's been pointed out, applications are mostly glue to bind 
libraries together these days.  I personally resisted this 'two languages' 
thing for a long while, I felt that a flexible language like C++ could 
stretch to both roles, especially with a good interpreter for the glue bits. 
The interpreter kept me busy for a few years and resulted in a severe 
allergy to C++;)  But it is in fact useful that the two languages _look_ 
different, so that the correct mental framework is loaded, which is a point 
alluded to in the Lightroom presentation. Lua-tcc strikes me as a step in 
the wrong direction, because you want to keep modules and glue as separate 
entities.

Lua is a natural successor to Tcl, but never had a GUI app framework like 
tk.  So anybody wanting to do a Lua application has to make choices: 
lua-gtk,LuaInterface,LuaJava,wxLua,IUP, etc, and basically have to do a 'due 
dilligence' investigation to see if a framework is mature enough, or 
currently maintained, etc.  (For example, I am really impressed with 
LuaJava, but it _is_ ownerless at the moment; lua-gtk is going through 
intense refactoring, etc)  This is particularly important if it's going to 
be used 'officially'!  This isn't a call for standardization, however, I 
personally like choice, but understand that choice is confusing, especially 
if there are a few potential duds in the box of chocolates.

Another issue is support for 'programming in the large', which these days is 
mostly seen as tool support but still feeds into language design.  The kind 
of happy hackery that works for 100 line scripts seems to lead to 
unhappiness in 100K applications (e.g. check out 'Dreaming in Code' about 
Chandler and Python); dynamic languages do not typically have explicit type 
annotations, so the tools have to work a lot harder.  Eclipse with Java 
totally impresses me, but Eclipse with other languages was underwhelming 
(haven't tried the Lua plugin yet, however).  We have the dynamic language 
paradox, usually expressed as 'conversion stories': former hard-line 
statically-typed X programmer discovers that they are enormously more 
productive in dynamic language Y for a weekend project, but miss the tool 
support with big projects. Maybe one needs explicit type annotations for the 
public interface of modules (defined here more loosely as a unit of code 
aggregation or programmer responsibility) but the internal module 
implementation can be more free wheeling?  Are there means to make dynamic 
programming productivity scale well?  More intelligent spell-checking? 
Source browsers that can hop around like mountain goats in million-line 
projects?

(My apologies for the mini-essay but it seems to be essay week on the Lua 
List ;))

steve d.