5 awkward and 5 awesome things about lua …
Hey,
I’ve been spending some time checking out lua, because I’m thinking about using it for scripting in games. I’m looking at it instead of tinypy because tinypy is slow and really needs some more TLC to be totally useful to me. However, after looking at lua for a while, I’m finding the things that make it feel awkward to me.
- List indexes starting at 1.
- For loops use [a,b] intervals
- No += operator.
- do / end keywords instead of { }
- List and Dict types combined into one
At the same time, I’ve found that lua is totally awesome. I mean, wow. Really slick stuff! Here’s 5 awesome things:
- Small codebase
- Faster than other dynamic languages
- Easy API integration
- Coroutines <- these are neat!
- State is serializable
So here are my thoughts:
- The first 4 awkward things are superficial, I could probably hack those into shape in a day or two. The 5th item (List + Dict) as one item is probably not something I can fix, but I could probably live with it.
- If I changed the language like that, and provided it for users to create mods for my games I would not be able to give them a link to the lua documentation, since it would not be accurate anymore.
Not quite sure what to do here. Lua seems great, though a few language design decisions seem awkward to me. I could change the language easily enough, but then I would be breaking all the lua documentation for my users.
Anyone got some language-design thoughts on this one?
-Phil
January 29th, 2010 at 3:18 pm
If you’re including it as a feature for your user base, then I’d recommend staying away from “fixing” the parts of the language you don’t like yourself. This is especially true for things such as list indexes.
Flip it around and consider how you would feel if you deployed a system with an embedded Jython interpreter, but the vendor had updated it such that list indexes start with a 1 instead of a 0.
Lastly consider the overhead in maintaining updated documentation and related artifacts.
January 29th, 2010 at 3:25 pm
You’re right, the first four awkward things are pretty superficial. As such, I think you should just leave them alone and learn to code that way. Every language is going to be different enough to have some awkward parts, but if the advantages of the language outweigh the disadvantages (and it sounds like they do, in this case), you learn it anyway. Think of human languages – do you try to change Chinese because it’s not the way you prefer. No, you do not.
January 29th, 2010 at 4:05 pm
Awkward:
No continue statement for loops (but a break statement)
String can except decimal number for chars preceded by a backslash but not hex. ’32’ but not ‘\x20’
~= instead of != or
January 29th, 2010 at 4:17 pm
I quite agree with you on the awkward things. The dictionary-is-array thing is the only serious one, and the solution seems to be to never use one for both. I have run into problems serializing and deserializing them, but that was with lua 4 not lua 5.
Some more awesome things that I only learned recently:
– Classes actually work very well, and are ridiculously simple to use and understand.
– Coolness: you can do MyFunc { a = 5, b = 3 } no problem; it’s equivalent to calling MyFunc ({ a = 5, b = 3}) and is based on the lua “single parameter function calls usually don’t need ()” principle.
Cheers, my vote is to not modify LUA, part of it’s beauty are it’s funny little idiosyncracies…
January 29th, 2010 at 4:34 pm
I like the way you think Phil. In your research so far, how much work is involved in creating a forked version of Lua with the changes you want?
Lua like other languages has its own eccentricities, some of which you list. It wouldn’t surprise me if there weren’t other people willing to adopt a version of Lua that was closer to the center. Of course I also cannot help but think replace 4 with “uses indentation instead of do/end keywords”.
Regarding documentation and language variant confusion, I see this being non-existent if head up your fork with a distinct name. Like Phil-Lua, and give it a tag line like “Now with more goat” and then the logo which is a picture of you riding your goat-driven cart. Ideally you would reuse the existing documentation, providing modified versions of it, which is an order of magnitude easier than writing your own (assuming that it is licensed in a way that allows this).
January 29th, 2010 at 4:54 pm
@Richard – the “catch” goes further than just a project renaming. Other drawbacks include:
– Being a language maintainer. I’m already “sort of” doing that for tinypy, and it’s a bit of work.
– If I diverge far from the lua codebase, I lose all the lua extras. For example, one of the main benefits I sighted was serialization, that’s an extension module. Another cool extension is the JIT project which I hear is -really- fast. If I diverge, I lose the JIT.
Another option is making a tinypy->lua compiler, which has certain appeal, at the same time, I might lose some of the cool lua features by doing that. I might also have to sacrifice some speed by wrapping lua tables in other objects to ensure things “work” the way tinypy does. At least in this option I wouldn’t lose any of the benefits of using lua.
January 29th, 2010 at 6:05 pm
For hysterical raisins: the first time I saw a mixture of list and dicts was in awk (called just “arrays” there), and they are actually hash tables. I believe it’s quite the same in lua.
January 29th, 2010 at 6:12 pm
@???????? – in lua they actually have a python style List and a python style Dict combined together. So is part ordered numbered array and part hash array. But not both – it isn’t an ordered hash array.
January 29th, 2010 at 11:32 pm
Check out the squirrel – http://squirrel-lang.org. It has C++ like syntax and is similar to lua in features and API. Not sure about speed. And I believe list and tables in squirrel are different types, if I remember correctly.
January 30th, 2010 at 2:27 am
Phil, IMHO points 1-4, though a bit unusual, aren’t really worth the effort. They’re just a matter of style and easy to get used to. Forking off the language is too much effort, and it will be hard to keep up with new features added to it, etc.
On the other hand, I’m kinda disappointed you wouldn’t use tinypy for this. tinypy could be a great competitor to Lua, given some effort, and I with it would go this route. Lua is cool, but Python is much better 🙂
January 30th, 2010 at 7:39 am
Yep, don’t bother fixing the language. You’re better off using the time on games instead of maintenance. Use what works best for now and keep an eye open for the language of your dreams. It will come 🙂
January 30th, 2010 at 8:46 am
How do you come to the conclusion that lua is faster than any other dynamic language? Speculations, rumors, or ???
Could you elaborate on this please.
ps: what kind of arrogant jerk has a website like this?
January 30th, 2010 at 9:12 am
Before you jump into lua bandwagon, I think you should also check out Angelscript. Its syntax is much more familiar, it performs quite well, and is really easy to integrate (I think it’s much easier than lua).
January 30th, 2010 at 11:22 am
@sopyer – I’ll check out squirrel!
@Eli – yeah, tinypy is pretty slow, doesn’t handle exceptions well, and a few other things. Maybe I should put more work into it. At any rate, I’m considering my options.
@carl – A few brief tests. It’s not enormously faster than python, so it’s not a major thing.
@tonic – I’ll check that language out too.
January 30th, 2010 at 1:12 pm
One quick note: Lua uses identical syntax for arrays and dictionary, but if you use a table as if it were an array, internally it stores it as an array. I worked this out when I got curious and dug into their handling code a little bit. So if your discomfort is caused by “storing arrays as hash tables is inefficient,” then be aware that Lua does NOT store arrays as hash tables. It just uses the same syntax for both, and does not make a type distinction between the two.
Note also that there is another difference — arrays have a magic member named “n” which gives the size of the array, but it only works on true arrays. Hash tables don’t keep count of their contents, so you either have to do that yourself (update ‘n’ on your own) or do without it.
If you start using an array as a hash table, of course, it converts it into a hash table.
January 31st, 2010 at 11:35 am
point 1 is very important. After years of using 1 based indexing in Pascal and fighting with extra +1 and -1 on many places i am confident that 0 based indexing is the only save way.
January 31st, 2010 at 5:09 pm
You might get more people helping with tinypy if you made a busybox module for it.
February 2nd, 2010 at 12:20 am
Lua’s awkward bits make it annoying for real-world use. Python’s not perfect, but it’s *more perfect* than Lua by far.
Your time might be better spent optimizing TinyPy than forking Lua.
February 4th, 2010 at 4:34 am
first, try to avoid on hacking bare lua parser, i did that, got my hands burnt. it’s easy but all you’ll end up is no-lua anymore with all the bad strings attached (unknown to users). this can be solved nicely by using http://metalua.luaforge.net so you use whatever syntax you’re comfortable with, while the users are left with a choice whether to use plain lua or your mod (the index 1 tables are still a neccesity for common co-op though).
second, why is tinypy slower? from superficial look at the code it seems to it’s rather luasqe (internalized strings, ssa-like register vm, tuples are pretty much heavier than lua’s stack arg passing, consts are inline though..), save for bloated -lgc which is probably a real performance hit. imho hacking tinypy to be more like luavm would be the way to go (also, having OO implemented on top of syntax/codegen, rather than vm would probably help) i suppose you’re familiar with the http://www.lua.org/doc/jucs05.pdf
February 4th, 2010 at 10:54 am
@brm – I don’t use -lgc, I use a hand rolled incremental collector, which could also use some work.
Thanks for the thoughts!
February 7th, 2010 at 7:15 am
Just one question: WTF is TLC?
February 8th, 2010 at 2:16 am
Mulling this over a bit more, I’d advise you to double down on improving TinyPy rather than move your investment to Lua. Lua doesn’t seem to be getting much traction outside of the game development community, whereas Python is widely adopted. And the momentum behind Python will continue to grow now that Google’s putting resources into the language (Guido works there, and Google’s built several products on Python).
Here’s some real data on usage of various dynamic languages: http://www.ohloh.net/languages/compare?measure=commits&percent=&l0=csharp&l1=javascript&l2=lua&l3=python&l4=ruby&l5=lisp&l6=-1&commit=Update
Lua rides the bottom of the graph, and Python beats out even JavaScript and C#. Lua’s great for embedding, but it’s an idiosyncratic also-ran language.
Perhaps you could modify LuaJit (or LLVM-Lua) to work with TinyPy bytecode to improve perf?
February 8th, 2010 at 2:12 pm
@Denilson: “Tender lovin’ care.”