lua-users home
lua-l archive

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


to add my own $1/50 to this discussion ... i've developed over the
last couple of years a couple of largish lua apps (~ 5k lines) and
have my own take on lua's strengths and weaknesses. my favourite (well
known) strength is that it is very well suited to processing
declarative files, i.e. to take a description of something written as
a big lua table, grind grind, spit out the result ... sort of like
XSLT but without the excruciating pain.

the biggest annoyance in writing a 5k line app is not the global/local
problem (as others have pointed out, there are good ways to resolve
that) but the fact that tables are not strongly typed: the data
structures you end up creating (the big sets of tables that link to
other tables) are not self-describing in the source code ... you can't
just "look for the struct declaration", you have to examing the source
to see what table keys get created where. thus there is a maintenance
problem, and lots of extra documentation is required about the data
structures that are used.

of course this is a *feature* of Lua and is part of what makes writing
small programs easy, but i think 5k lines is about the complexity
limit for me :)

russ. 



On Sat, 19 Feb 2005 02:07:39 +0000, David Given <dg@cowlark.com> wrote:
> On Friday 18 February 2005 22:11, PA wrote:
> > On Feb 18, 2005, at 22:06, Glenn Maynard wrote:
> > > I'm not saying one can't; I'm saying one normally does not.  Lua is an
> > > extension language; extending is what it's good at.  If you're writing
> > > a whole application in it, you'll quickly find out what the difference
> > > is--it's not good at it, and isn't supposed to be.
> >
> > Perhaps... time will tell... on the other hand... if people didn't
> > experiment with Lua in new and weird ways... Lua would still languish
> > as an obscure "data entry language" of sort:
> [...]
> 
> I use Lua as a scripting language, to knock up simple throwaway programs
> quickly. The two most complex programs I've written in it are a Makefile
> generator --- which works very nicely --- and a C++ preprocessor that expands
> special syntax for our platform. Both of these highlighted Lua's problems as
> an application programming language; basically, it's not scalable. It's very,
> very good at writing *small* pieces of code and very, very bad at writing
> *large* pieces of code. You can get around this with discipline, but frankly
> if I was writing a large application I'd use something else --- Ruby,
> perhaps.
> 
> Lua's biggest problem when writing large applications is the hoary old
> chestnut of misspelt global variables. It's *amazingly* painful not to be
> warned if you misspell a variable name... your program just doesn't work,
> sometimes in strange ways. A lesser problem is the fact that variables are
> global unless specified local, which is the opposite to most other languages.
> 
> Personally, I don't think these are big issues; Lua's not an application
> programming language, it's an extension language, and the requirements are
> different. Perhaps one day it would be nice to have a different compiler for
> the VM, whose input language had a different emphasis, but I don't see it
> happening soon. I also don't see Lua's semantics being changed, because the
> existing semantics are too useful for Lua's primary purpose.
> 
> --
> "Curses! Foiled by the chilled dairy treats of righteousness!" --- Earthworm
> Jim (evil)
> 


-- 
Russ Smith
http://www.q12.org/