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

[askok@...]

Seems Roberto's comment on the future of Lua spawned some 
interesting, and needed discussion.
I share many of Steve's experiences, about the problems 
scaling "scripting" to actual application size projects 
(>1000 lines of Lua).
Here's what to do:

- start using type descriptions as an addon to "typeless" 
Lua.   LuaSub and MetaLua already provide this.
- invent a "lua-lint" tool, which would use the same type 
descriptions to check as much of validity of the code, 
statically, as possible.
In my understanding, the lint-like tools exist in specific 
companies internal usage, but none is there out in the 
open.  To me, this (and the GUI) seems to be the missing 
piece to "future Lua". Other pieces are syntax modding 
(already mentioned), LuaJIT 2.0, LuaRocks.
What's interesting here is that none of these need any 
changes from the core language whatsoever. Meaning, from 
Roberto's viewpoint the future may well be "scripting" but 
for some other of us, the future may be "hardwired 
scripting". The futures don't exclude each other.
-asko

p.s. One thing I'd like from Lua itself, is inclusion of a 
tolua-type interface in the language pack itself.

On Sat, 13 Sep 2008 11:22:00 +0200
 "Steve Donovan" <steve.j.donovan@gmail.com> wrote:
> '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.