A Look at Lua

An overview of the compact yet powerful Lua programming language.
Embedding and Extending

Although taking a look at embedding and extending Lua is outside the scope of this article, I touch on a few concepts here. First, the Lua API is very straightforward. Its design eliminates the need for manual reference when embedded in C code (unlike Python's API). Like the language, Lua's C API (for embedding) is fairly minimalistic. If you need advanced functionality, you can use a secondary library that is primarily made up of preprocessor macros.

Second, C and C++ are not the only languages in which Lua can be embedded. Tao.Lua provides straight .NET and Mono bindings to Lua, and LuaJava allows scripts written in Lua to manipulate Java components. LuaJava allows Java components to be accessed from Lua with the same syntax that Lua uses for accessing its native objects. It also allows Java to use a Lua interface so that any interface can be implemented in Lua and passed as a parameter to any method. The method's result (when called in the Java program) is called in Lua, and the result is sent back to Java.


Lua is a flexible, powerful, compact language that can be used and extended in myriad situations. Its focus on simplicity makes for easy debugging and has attracted many users. Its simple, powerful syntax provides flexibility because of Lua's metamechanisms. The small, fast interpreter uses less resources than Python, and its syntax allows for easier code readability. Its simple C API makes embedding a breeze. Whether you are doing data processing, GUIs or game programming, you will find a use for Lua.

Joseph Quigley has been a Linux user for more than two years. He enjoys fiddling with different Linux distros and exploring new programming languages.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Not really a fair treatment of Python though, is it?

magnus's picture
  1. "There is no need to worry about different types of integers." There is no need to do that in Python either nowadays. The conversion between "regular integers" and long ones is done automagically. Take the following function:

    def frac(n):
    if n == 0: return 1
    else: return n * frac(n - 1)

    Evaluating frac(10) gives the result 3628800 while frac(30) returns 265252859812191058636308480000000L.

  2. "You can add a float, long integer or a double to any other type of integer or number without a hitch in Lua. In contrast, doing this can cause programs written in Python 2.4 or older versions to crash." Really? I've never heard of this problem. Do you have any references?
  3. "In contrast to Python, Lua does not focus on 100% backward compatibility." That Python would focus on 100% backward compatibility is just plain wrong. Code I've written broke when moving from version 2.4 to 2.5 due to changes in generators. This is the only time I've personally been bitten by it but every version of Python has broken something from earlier versions. AFAIU Python 3000 will break a whole lot of older Python programs.
  4. "Unlike Python, global variables do not need to be declared." They don't need to be declared at all, not on a global level. If a function wants to access a global variable then _it_ has to declare it as global. Contrast that to the following point.
  5. "Exactly the opposite of Python, most variables in Lua are global by default, and you must declare the variable "local" to make it a local variable rather than assuming that all variables are local." Variables in Python are local by default, which in my experience better reflect how variables are used by programmers.
  6. The for loop is a little more complex in Python than it is in Lua, because Python needs to know the key to be able to get the key's value." It's possible to iterate over both key and value in Python as well:

    h = {1:'hello', 2:'world'}
    for k, v in h.iteritems():
    print k, v

In general it's a good article, it shows off some interesting points in Lua. In order to make a comparison between two languages it's necessary to have very good knowledge of both languages, otherwise there's a real risk that one language is the favourite simply because the author knows that one the best. This piece definitely suffers from that.

I also believe it would have been better without the author's personal opinions on aesthetics sprinkled across the piece.