Re: Lua Strengths/Weaknesses and usage info

[David Jeske <jeske@...>]

On Fri, May 18, 2001 at 01:27:45PM -0400, Christian Vogler wrote:
> >    The troubles with Lua in this project have been: (a) It's weak typed,
> >    and debugging is somewhat difficult in the context of a game where 
> >    I've not built an interactive Lua debugger.
> 
> 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.

I clearly need to do this.

> > (b) It's hard for others to
> >    understand the Lua code, both because it's weak typed, and because 
> >    (like all class-ish lua) I had to build my own inheritence mechanism and 
> >    the weird syntax makes the code more confusing. 
> 
> 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)
      local xpos,ypos;

      xpos,ypos = whoIhit:getPos();
      xpos = xpos + 5;

      whoIhit:setPos(xpos,ypos);
end

When trying to figure this out, one needs to know what type of object
"whoiIhit" is, and get a list of the methods and properties available
in that object. In Lua, this is only possible if I build an
interactive debugger environment, and actually stop the script code
right when one of these event handlers is called. However, once the
code is changed, it's going to have to reset and reload alot of stuff
to be able to run his the code.

If I could specify types, this would be simple, it would say:

ge_collision = function(self,number x,number y,Sprite whoIhit)
      local xpos,ypos;

      xpos,ypos = whoIhit:getPos();
      xpos = xpos + 5;

      whoIhit:setPos(xpos,ypos);
end

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

This isn't so much a problem in built-in event callbacks, because my
sprite documentation explains them. However, when looking at someone's
arbitrary script code for an object, it's hard to track down what
method arguments (or object properties) are of what type.

> Or do you mean the difference between static and dynamic typing?

No. I'm taking about the difference between strong and weak typing. I
just want the ability to provide strong type checks in places where
types are known.

If I wanted the Sprite code in a static typed language, I would have
just left it in C++. 

[ stuff about static vs dynamic type ]

> In such cases I would argue that the code is actually easier to
> understand than the statically typed version.

I agree that dynamic typed code can normally be much more brief. I
like using languages which have nice robust datatypes, garbage
collection, and have some level of dynamic typing. However, there are
lots of things in all software which simply are not dynamic, and it's
annoying to me when the program will happily load lots of invalid code
just because everyone who seems to like dynamic typing seems to equate
it with weak typing.

[[steve: That's why I'm not using something like EiC. Because it's
basically pointer-safe C, with no GC, and no abstract datatypes like
lists and hash tables. ]]

The closest thing I've seen is "Pike". It is a dynamic scripting
language like Lua, Python, and the rest, with garbage collection,
abstract datatypes such as lists/hashes, etc. However, I tried it out
and even though it allows you to (optionally) declare static types all
over, right now it does not check most (a) arguments to
functions/methods, (b) names of methods against object types to see if
the method exists. So it's not useful enough to justify switching from
Lua.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net