[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: My wish list :) [RE: How can we make lua better?]
- From: Asko Kauppi <Asko.Kauppi@...>
- Date: Wed, 5 Jun 2002 11:06:31 +0300
Thinking about it, there's not much "unnecessary" that could be reduced from
Lua, is there... The great point about it (one of them!) is that the
'advanced' features such as tag methods etc. don't have to bother the casual
coder at all. You can even read only the first pages of the manual and start
using it right away!
Here's my current wish-list ( and yes - I do try to keep it small! ):
1) Extensions to stand-alone interpreter (without recompilation)
Standard way of loading in extensions (C/C++ dlls/so's intended to be used
from Lua) without recompiling the stand-alone interpreter. This does not
need changes in the language itself, just the interpreter (+ some docs).
I'm currently working on this and will be posting some results here soon.
Thanks for all the hints I got about current loadlib's etc. a while back!!!
2) += and -= operators
I _really_ miss these and they'd make code look more simple so it's arguable
that this 'feature' would actually be a simplification. :)
Currently: counter = counter + 1
Would be: counter += 1 (as in C)
I do _not_ miss C's ++ / -- since already the form above eliminates
double-writing the variable name. Sometimes they become longer, especially
when handling objects.
Also: string ..= "something appended to the string"
...would be a logical extension of the same theme.
3) Using hex char codes within strings
For 8-bit ANSI: "\xab" (and "\xabcd" if 16-bit strings are to be supported).
The current decimal "\ddd" notation is bad for many reasons (e.g. clash with
C's usage of octals that way). I would drop it away with no regrets!!
4) 'File find' etc. in standard libs would be fine.
5) Joining Qt (graphics toolkit) and Lua - has anyone done this yet?!?
As you can see, only (2) and (3) have with the language itself to do.
Would be interesting to get votes for these :) and to hear your
As you can see, neither I have any of the (B) category (reducing /
simplification ideas) that Martin was calling for. Perhaps it just tells
that the designers of Lua have done a brilliant job! *aplauds to them* :)
I think there's two kinds of "bloat" possibility here, within the
language and within the libraries. The first is bad, the second may even be
good. So as long as we grow a nice, "feature-rich" :) set of extensions /
libraries, the ones only wanting "lua--" can live happily without them. If a
feature is introduced within the language, I don't think it should be taken
away (without an upgrade path or tool to support the old source).
Flextronics Design Finland
Box 23, 39201 Kyröskoski, Finland
PGP: 8348 2AE1 CEDC C81A 2255 2439 E4C8 7308 825E 32C3
> -----Original Message-----
> From: Martin Hollis [SMTP:firstname.lastname@example.org]
> Sent: Tuesday, June 04, 2002 8:58 PM
> To: Multiple recipients of list
> Subject: How can we make lua better?
> If I may be so bold, I would like to say something about the long term
> development of lua, which also applies to all things.
> Lua is a marvellous language, which ably fills a niche. It is small in
> memory, simple to learn, powerful to use, and efficient to run.
> There is always much discussion on this list on the subject of improving
> lua. This is a good thing, and it is a great list.
> However, such discussion, as a rule, is about features that might be added
> to the language, in order to make it more powerful. This can be
> categorized as:
> A) "How can we make lua more powerful (and more complex)".
> The problem is, there is little discussion or thought on the subject of:
> B) "How can we make lua simpler (and not less powerful)".
> Sadly, B) is harder. Much harder. Orders of magnitude harder. A) is easy.
> Nearly anyone can do it. It's that easy. It's like falling off a log. You
> need a feature, you imagine it, you suggest it. But very few people can
> achieve or contribute towards B). I, for example, have nothing to
> contribute to B (except this plea). And B) takes a special kind of
> attitude, a kind of zen-like ascetic. You could even say genius.
> Because A) is easy, and B) is hard, we have concepts like 'featuritus',
> 'bloat', and we have lightweight languages like Java, and powerful
> languages like C++, that developed over many versions, by iterating the
> harmless step: 'Add power by adding one feature'.
> Even cancer grows slowly.
> My plea:
> I think I can sense the majority view in this list. We don't want bloat.
> don't want 'lua++'. If anything, we want 'lua--'.
> I suspect the creators of lua are deeply influenced by the content of this
> list, so I would simply like to implore and encourage everybody on it to
> think about the question "How can we make lua simpler (and not less
> If 50% of the effort is focused on this question, then perhaps we will
> a way. How to do this? Some possibilities are:
> * Generalize and abstract to combine features
> * Refactor features
> * Elide warts
> * Normalize to written or unwritten standards
> Is it possible for lua n+1 to have 4 more features, and 4 fewer features
> than lua n? If it is, then lua could live forever, and I will be very
> Otherwise, sadness, and quiet acceptance of lua n.
> Martin Hollis.
> I release this text into the public domain. Credit is nice.
> PS This post is not related to any particular discussion presently
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.