History of Lua aside... note about game usage!

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Eric Tetz-2
--- Steve Dekorte <[hidden email]> wrote:
> 
> David Jeske wrote:
> You might try EiC(http://www.kd-dev.com/~eic/) if you're looking for a scripting language based
> on C's syntax.

Quite a few scripting languages are "based on C's syntax" - whereas EiC actually interprets ANSI
C.

Just wanted to clarify that.

Cheers,
Eric

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Reply | Threaded
Open this post in threaded view
|

GPL source release of my game..

David Jeske-3
In reply to this post by David Jeske-3
BTW: I made a GPLed source release of one version of my game
engine. It's not a playing game (yet).. although it's getting much
closer now that I have time to work on it.

If you're interested in seeing Lua in action, or want to help suggest
a better syntax for lua objects, or want to see my multiple
inheritence 'parent slot inheritence cache' (which supports
multi-level multiple inheritence without all the performance penalty),
pull down the game and check it out.

http://www.chat.net/~jeske/Projects/HZ/

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Lua Strengths/Weaknesses and usage info

Philippe Lhoste
In reply to this post by David Jeske-3
Steve Dekorte wrote:
> David Jeske wrote:
> > ge_collision = function(self,number x,number y,Sprite whoIhit)...
> >
> > ...and now everyone knows exactly what object type "whoIhit" is.
> 
> You might try using a naming convention when the type isn't clear:
> 
> ge_collision = function(self, x, y,whoIhitSprite)
> 
> Or better yet:
> 
> function ge_collisionAtX_Y_with_(self, x, y, aSprite)
> 
> This way a developer who looks at the method's use doesn't has to look 
> at it's declaration to determine what the args are for.
> 
> Steve
 
Or just use some comments...

ge_collision = -- Event callback: Manage collision
function(
  self,   -- object
  x,      -- horizontal position
  y,      -- vertical posiition
  whoIhit -- Sprite
)

Of course, you must like this kind of style, and expect other programmers to
follow it.

-- 
--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--

Sent through GMX FreeMail - http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Reuben Thomas-4
In reply to this post by Christian Vogler-2
> My biggest gripe with lua is the lack of libraries that make
> general-purpose scripting hard and verbose.

Or alternatively, which force you to write your own libraries! I've never
found Lua verbose (though admittedly I've not programmed much in other high
level languages with good libraries such as Java, Perl or Python); but I
have found that I've accumulated quite a few utility routines after just a
little Lua scripting. However, a lot of these are very general purpose or
widely useful, e.g. die(), warn(), wrappers for the file routines which call
die on error, and general list operations such as mapping a function over a
list, applying a function to each element of a list, or concatenating two
lists.

> image.0001.pgm
> image.0002.pgm
> ...
> image.0500.pgm
>
> >From this directory we need to find out how many images are there and
> what the first and last frames are. From lua, this turned out to be
> surprisingly hard to do. We eventually settled on a combination of
> system("ls") and the string pattern functions, but the result is
> neither robust (we end up with broken pipes frequently), nor easy to
> understand.

What about using poslib? POSIX has support for dealing with directories.

> We've partially gotten around the problem by giving access to an
> interactive lua interpreter from the main program. This lets us
> inspect and modify code and variables at run time.

This is one of Lua's coolest features. I used it while writing an
(unfinished) Mini-Scheme interpreter, and once I realised I could do it it
was my single most powerful debugging technique.

-- 
http://sc3d.org/rrt/ | maxim, n.  wisdom for fools


Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Reuben Thomas-4
In reply to this post by David Jeske-3
> If I could specify types, this would be simple, it would say:
>
> ge_collision = function(self,number x,number y,Sprite whoIhit)

There's nothing to stop you putting this sort of information in comments,
although admittedly because Lua's only comment style is a rest of line
comment, this is hard to do in the obvious way:

go_collision = function(self, /* number */ x, /* number */ y, /* Sprite */
whoIhit)

But still, you can write the type in a LuaDoc-style comment. I admit that
this sort of thing requires discipline and a type system that makes you do
it is better.

-- 
http://sc3d.org/rrt/ | Quidquid latine dictum sit, altum viditur (Anon)


Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Christian Vogler-2
In reply to this post by Reuben Thomas-4
On Sat, May 19, 2001 at 03:24:36PM +0100, Reuben Thomas wrote:
> Or alternatively, which force you to write your own libraries! I've never
> found Lua verbose (though admittedly I've not programmed much in other high
> level languages with good libraries such as Java, Perl or Python);

I've programmed a lot in Perl and also a bit in Python. I find that my
lua programs are longer by about a factor of 1.2-1.5. Granted, compared to
C, or even Java, this is not verbose, but as far as "scripting"
languages (scripting in quotes, because I think that this attribute
does a lot of languages gross injustice) go, lua tends to be on the
more verbose end. YMMV.

> have found that I've accumulated quite a few utility routines after just a
> little Lua scripting. However, a lot of these are very general purpose or
> widely useful, e.g. die(), warn(), wrappers for the file routines which call
> die on error, and general list operations such as mapping a function over a
> list, applying a function to each element of a list, or concatenating two
> lists.

So did we. As a matter of fact, map() was one of the first functions
we wrote, although its utility has diminished a little with the new
for syntax in lua 4.0. Perhaps at some point we should see if we can
accumulate the most useful functions from everyone into a
general-purpose library.

> What about using poslib? POSIX has support for dealing with directories.

This is probably what we will do sooner or later. The one thing I
don't like about it is that I think that this should be a
operating-system-neutral abstraction on those OSs that support
directories. POSIX is not as portable as it could be. 

- Christian

Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Gavin Wraith-2
On Sat 19 May, Christian Vogler wrote:

> > What about using poslib? POSIX has support for dealing with directories.
> 
> This is probably what we will do sooner or later. The one thing I
> don't like about it is that I think that this should be a
> operating-system-neutral abstraction on those OSs that support
> directories. POSIX is not as portable as it could be. 

Remember that some OSs not only have a 'filetype' attribute,
missing in Unix, DOS, etc, (i.e. not part of the file's name)
but also have different flavours of directory. 
RISC OS for example, has penny-plain directories
corresponding to the usual notion and also a twopence-coloured
kind, called an 'application' for packaging guess what. The
GUI treats them differently. It is a useful distinction. 
Theoretically the situation is even more complicated, because
RISC OS supports an abstraction called a 'filing-system',
whose instances can be user definable, to support filing-system 
independence of the user interface. In practice there are not more
than a dozen or so, because they are quite fiddly to create.

-- 
Gavin Wraith ([hidden email]) or ([hidden email])
Home page: http://www.wraith.u-net.com/


Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

J. Perkins-2
In reply to this post by Steve Dekorte-4
Steve Dekorte wrote:


David Jeske wrote:

ge_collision = function(self,number x,number y,Sprite whoIhit)...

...and now everyone knows exactly what object type "whoIhit" is.


You might try using a naming convention when the type isn't clear:

ge_collision = function(self, x, y,whoIhitSprite)


Or how about:

-- parameters:  x,y  - location of collision, whoIhit - the colliding Sprite
ge_collision = function(self, x, y, whoIhit)

Lots of options for documenting code that don't involve changing the language.


Jason
379



Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

John Belmonte-2
In reply to this post by David Jeske-3
David Jeske wrote:
> > How does weak typing make code harder to understand?
>
> It makes it harder to understand because when someone's looking at an
> event callback in my game, it looks like:
>
> ge_collision = function(self,x,y,whoIhit)
> [...]

One thing to realize is that generic programming in C++ has the same issue,
and it's usually considered an advantage.  With generic programming you
don't care about the type of an object, only its interface.  Like others
have responded, a little documentation is helpful.  Here is David's function
again (simplified somewhat):

    -- whoIhit object must have get/setPos member functions
    function ge_collision(whoIhit)
        local xpos, ypos = whoIhit:getPos()
        whoIhit:setPos(xpos + 5, ypos);
    end

Here is a C++ version with the same meaning.  The whoIhit argument may be
any type, it just needs to have the proper member functions:

    // whoIhit object must have get/setPos member functions
    template <class T> void ge_collision(T& whoIhit)
    {
        float xpos, ypos;
        whoIhit.getPos(&xpos, &ypos);
        whoIhit.setPos(xpos + 5, ypos);
    }

Recently in the C++ community everyone is jumping on the generic programming
bandwagon.  What that language has taken years to evolve support for, Lua
has always been able to do... and with simpler syntax.

-John



Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Terence Martin-2
> Recently in the C++ community everyone is jumping on the generic
programming
> bandwagon.  What that language has taken years to evolve support for, Lua
> has always been able to do... and with simpler syntax.

This is the reason I like objective-c so much, because you can do exactly
this (except you don't need templates). When I discovered lua, it was
exciting to note that it is ridulously easy to bind objective-c classes to
lua scripts with minimal effort.


Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Reuben Thomas-4
In reply to this post by Christian Vogler-2
> > What about using poslib? POSIX has support for dealing with directories.
>
> This is probably what we will do sooner or later. The one thing I
> don't like about it is that I think that this should be a
> operating-system-neutral abstraction on those OSs that support
> directories. POSIX is not as portable as it could be.

Granted, and there are a lot more like this. But this still seems to be
about the libraries rather than the language; I'm interested to know if
you think that Lua is *inherently* more verbose than Perl or Python.
Personally, I struggled with Perl for 2 or 3 years of occasional use, and
each time I came back to it I'd forgotten some key bits of magic, and
spent most of my time while writing trivial scripts looking these up in
the Camel book, which in some ways is not a good reference work.

Even though I only program in Lua a little bit, it's small size and good
reference manual make it easier to remember and use in this respect, and
I've started using it for things I would've used Perl for before.



Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Reuben Thomas-4
In reply to this post by John Belmonte-2
> Recently in the C++ community everyone is jumping on the generic programming
> bandwagon.  What that language has taken years to evolve support for, Lua
> has always been able to do... and with simpler syntax.

...but in a strongly-typed language you can be sure you're doing the right
thing; the compiler will tell you if you aren't. In Lua you can't.


Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

John Belmonte-2
Reuben Thomas wrote:
> ...but in a strongly-typed language you can be sure you're doing the right
> thing; the compiler will tell you if you aren't. In Lua you can't.

I've been thinking about that since my last post.  Actually you *can* be
sure (by writing functions that carefully check their arguments, etc), it's
just that the checking is done at run-time.

By the way... some consider C and C++ to be weakly-typed.  (See
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?weak+typing.)  For our
discussion the terms statically-typed  and dynamically-typed may be more
appropriate.

-John



Reply | Threaded
Open this post in threaded view
|

RE: Lua Strengths/Weaknesses and usage info

Samson-3
In reply to this post by David Jeske-3
>You might try using a naming convention when the type isn't clear:
>
>ge_collision = function(self, x, y,whoIhitSprite)
>
>Or better yet:
>
>function ge_collisionAtX_Y_with_(self, x, y, aSprite)
>
>This way a developer who looks at the method's use doesn't has to look 
>at it's declaration to determine what the args are for.

You could also include something like

assert(aSprite.instanceOf("Sprite") );

As the first line of the method. As type checking is most important during
development you
could remove these lines for speed/size gains when ready for release.

lcs

Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Reuben Thomas-4
In reply to this post by John Belmonte-2
> By the way... some consider C and C++ to be weakly-typed.  (See
> http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?weak+typing.)  For our
> discussion the terms statically-typed  and dynamically-typed may be more
> appropriate.

I think strongly-typed and weakly typed is more important here; I don't so
much care when my errors are caught as that they are caught at all,
without my having to write the type-checking code by hand. If you do
generic programming in C, which is weakly typed, then you have this
problem; C++ can be strongly typed if you use it right (as I understand
it).


Reply | Threaded
Open this post in threaded view
|

RE: Lua Strengths/Weaknesses and usage info

Philippe Lhoste
In reply to this post by David Jeske-3
Christian Vogler wrote:
> On Sat, May 19, 2001 at 03:24:36PM +0100, Reuben Thomas wrote:
> > Or alternatively, which force you to write your own libraries! 
> I've never
> > found Lua verbose (though admittedly I've not programmed much 
> in other high
> > level languages with good libraries such as Java, Perl or Python);
> 
> I've programmed a lot in Perl and also a bit in Python. I find that my
> lua programs are longer by about a factor of 1.2-1.5. Granted, compared to
> C, or even Java, this is not verbose, but as far as "scripting"
> languages (scripting in quotes, because I think that this attribute
> does a lot of languages gross injustice) go, lua tends to be on the
> more verbose end. YMMV.

Verbose is in the eye of the beholder... In a previous thread, we talked
about APL, which is very terse, but a bit hard to understand without being a
disciple... Forth is a bit like that too. Perl is terse, but quite cryptic. Etc.
I thought that modern programming stress out the clarity of code over the
conciseness. Ie. on maintenability over the comfort of the programmer (the one
who write the code, not the one who have to maintain it!).
 
> > have found that I've accumulated quite a few utility routines 
> after just a
> > little Lua scripting. However, a lot of these are very general 
> purpose or
> > widely useful, e.g. die(), warn(), wrappers for the file 
> routines which call
> > die on error, and general list operations such as mapping a 
> function over a
> > list, applying a function to each element of a list, or 
> concatenating two
> > lists.
> 
> So did we. As a matter of fact, map() was one of the first functions
> we wrote, although its utility has diminished a little with the new
> for syntax in lua 4.0. Perhaps at some point we should see if we can
> accumulate the most useful functions from everyone into a
> general-purpose library.

Yes! I see often here remarks on useful things made by mailing list members,
but when I search for Lua source code examples on the Web, I don't find
much... This is quite frustating, even if I understand that some code can't be
released because of NDA, close source development, etc.

I took a look at the Euphoria site mentionned previously. It is a close
source, semi-free language, available only on two platforms. Yet, it has
attracted a number of fans, providing a lot of code snippets or full blown programs.
That, too, is a measure of the popularity of a language.

Now, the comparison isn't fair, since Lua main goal is to be embedded in
applications, while Euphoria is a standalone language. So the population of Lua
users is quite smaller (mostly programmers whose aim is to do a program with
support of Lua) than the Euphoria one (programmers whose aim is to do
programs in Euphoria).

Lua can be used standalone, but currently (4.0), there isn't much support
for external libraries (callable from programs executed by the standard Lua
interpreter), no Windows support (yet), etc.

I mention Windows because, you think what please you about it, but it is
still the most used system in the world, so it has a good user base.

> > What about using poslib? POSIX has support for dealing with directories.
> 
> This is probably what we will do sooner or later. The one thing I
> don't like about it is that I think that this should be a
> operating-system-neutral abstraction on those OSs that support
> directories. POSIX is not as portable as it could be. 
> 
> - Christian
> 

PS. I can't reach Lua site today?

Regards.

-- 
--._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
--´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`·._.·´¯`--

Sent through GMX FreeMail - http://www.gmx.net


Reply | Threaded
Open this post in threaded view
|

RE: Lua Strengths/Weaknesses and usage info

Reuben Thomas-4
> no Windows support (yet)

There's arguably some support in the form of lua-gtk+. I suppose this means
Windows support in the sense of "can write GUIs that run on Windows" rather
than "can access the Win32 (or some other native Windows) API". But writing
such wrappings is pretty easy for Lua.

-- 
http://sc3d.org/rrt/ | art, n.  romanticized mundanity


Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Christian Vogler-2
In reply to this post by Reuben Thomas-4
On Mon, May 21, 2001 at 09:51:25AM +0100, Reuben Thomas wrote:
> Granted, and there are a lot more like this. But this still seems to be
> about the libraries rather than the language; I'm interested to know if
> you think that Lua is *inherently* more verbose than Perl or Python.

That depends on what criterion of verbosity you use. For
object-oriented programming it is, because the class mechanisms are
not built into the language. For functional and imperative programming
I think that lua could be roughly even with Perl and Python if it had
better libraries.

Two notes: First, I'm not counting block begin and block end markers
toward verbosity. Python does not need them, but I don't think that
the difference in lines of code (LOC) is enough to make programming in
one language more cumbersome than another. Second, I am assuming that
you want to write readable and maintainable Perl, not line-noise.

> Personally, I struggled with Perl for 2 or 3 years of occasional use, and
> each time I came back to it I'd forgotten some key bits of magic, and
> spent most of my time while writing trivial scripts looking these up in
> the Camel book, which in some ways is not a good reference work.

This is why I like Python so much. It is a quite clean language,
although it has more warts than lua. There is no "magic" to remember,
and on top of that it has very powerful standard libraries.

- Christian

Reply | Threaded
Open this post in threaded view
|

Re: Lua Strengths/Weaknesses and usage info

Christian Vogler-2
In reply to this post by Philippe Lhoste
On Mon, May 21, 2001 at 01:13:58PM +0200, Philippe Lhoste wrote:
> Verbose is in the eye of the beholder... In a previous thread, we
> talked about APL, which is very terse, but a bit hard to understand
> without being a disciple... Forth is a bit like that too. Perl is
> terse, but quite cryptic. Etc.  I thought that modern programming
> stress out the clarity of code over the conciseness. Ie. on
> maintenability over the comfort of the programmer (the one who write
> the code, not the one who have to maintain it!).

Those two goals are not mutually exclusive. Python is the best example
of that. As I said in my other message, lua currently is more verbose
than both *maintainable* Perl and Python, but that seems to be mostly
because of the lack of libraries.

> Yes! I see often here remarks on useful things made by mailing list
> members, but when I search for Lua source code examples on the Web,
> I don't find much... This is quite frustating, even if I understand
> that some code can't be released because of NDA, close source
> development, etc.

Right now I am waiting for lua 4.1 to be released first, before I
release utility code, because there are two key features missing:
require and weak tables. Without them the code won't run on a default
lua installation.

- Christian

123