lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

'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.