[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Is "scripting" truly Lua's future?
- From: "Steve Donovan" <steve.j.donovan@...>
- Date: Sat, 13 Sep 2008 11:22:00 +0200
'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
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
(My apologies for the mini-essay but it seems to be essay week on the Lua