The "I Love Lua, but..." post

[kikito]

I've been thinking about writing a post like this for a while now.

Lua is very likable. I'm sure all of you guys love it, otherwise you'd probably would spend your time with pygame or some other engine in some other language.

But I'm sure that there are things here and there that you don't like.

Yesterday I spoke about Lua on an agile meeting, and today someone from that meeting sent me this article about Lua. Which links to this other article.

I'm not saying that I agree to what those articles say - but I think that inspecting your tools, and knowing their (potential) short comings, is usually a healthy idea.

So I thought - hey, we should start a thread about the "things that we don't like" in Lua.

So here's the list of things that I don't like. I've more or less sorted them out in descendant order of importance.

Disclaimer: I still love Lua.

• Lua's "global by default" idea. I think a "local by default" or even a "nothing by default" (i.e. you always have to specify either "global" or "local" are better, except for maybe trivial programs.
• The : operator. I would have preferred that foo.bar(baz) included foo as the first parameter of bar by default. I would not mind that the : operator was put there for the opposite case. Incidentally, I would not mind if "self" was implicit in all functions. In short: I prefer the Javascript way.
• Lua doesn't handle directories natively. This makes using require() very frustrating, because you can't use relative paths. The fact that folders are not supported on ANSI C doesn't justify that they aren't in LUA IMHO. If you are not going to acknowledge that there's a filesystem underneath, then don't give me a require() function, and make me require stuff from C. Or at the very least, give me a require function that can be used with relative paths.
• That the standard libs offer so little - specially table and string. I don't like inconsistency on what is provided and what not. math for example has sin and cos, but then it has foor but not round.
• Related to the previous one: Lua invents its own regexp, and then bases most of its string-related stuff on it.
• list-returning function calls used as parameter only "expand" if they are the last parameter. Otherwise, they return the first value only. I think this is done because some functions in the standard lib actually return two values, and people can use them without noticing anything, treat them as returning one value, and the code will work. I would prefer having two versions of the methods in the library - the "usual" one returning just the first value, and an "extended" version returning all of them, and expanding all functions.
• Local variables are second-class citizens. You have to use the debug lib for manipulating them. That should be built-in: if I have a _G, I'd also like to have a _L.
• metamethods aren't looked up using __index. This is kind of a edge case, but it's giving me lots of trouble with middleclass-extras: if table t1 has t2 as its index table (getmetatable(t1).__index=t2), and t2 has an index in t3, and t3 defines a method called __tostring, then tostring(t1) should use that method. Well, it doesn't, because in Lua metamethods are looked up differently than regular methods (with a rawget on the metatable, not with metatable.methodname)
• Not being able to use the dot notation on table members when the keys are reserved words. I'd really like to be able to say my.function = function() instead of my['function'] = function() ... . And yes, I can say my.func instead. I still don't like it. This bugs me because it is a trivial parsing problem.
• ~= instead of !=, and .. instead of +

Please feel free to add your own lists or comment.

[BlackBulletIV]

Pretty much agree with everything here. The no-directories thing I think is one of the most absurd, it's blending high-level with lower-level, and plus it has given me a tonne of problem before.

I think the logic behind global by default is that it makes sense in files. When you have global by default, files are just functions. If it was local by default, files would have to be treated differently.

As for me, these are things I've said before:

• No compound operators. Seriously adds to typing.
• No bitwise operators. Very limiting when it comes to integer manipulation, such as hashing and color integer manipulation.

Of course there's the no standard OOP system thing. I think I'd prefer Lua with a standard OOP system, at least for purposes like LOVE. But then we wouldn't have all this fun hacking around making our own!

[nevon]

I agree with everything you just said (both of you)!

Incidentally, I like Lua and Python equally, but I find Löve to be so much easier to use than Pygame. Plus, the community is awesome. If Pygame was a bit easier to use, I'd probably dump Löve in favor of it.

[vrld]

Yesterday I spoke about Lua on an agile meeting, and today someone from that meeting sent me this article about Lua. Which links to this other article.

I read the former article just yesterday and the other one a while ago. While he raises some valid points, most of his arguments target embedding Lua using the C api rather than the language itself.

Lua's "global by default" idea. I think a "local by default" or even a "nothing by default" (i.e. you always have to specify either "global" or "local" are better, except for maybe trivial programs.

That one annoys me too. I would prefer if variable scoping was like it is in C++: only visible the block they are defined in and it's subblocks.

Lua doesn't handle directories natively. This makes using require() very frustrating, because you can't use relative paths. The fact that folders they are not implemented on ANSI C doesn't justify that IMHO. If you are not going to acknowledge that there's a filesystem underneath, then don't give me a require() function, and make me require stuff from C. Or at the very least, give me a require function that can be used with relative paths.

Other languages (C++, C, Lisp, ...) are also file-system agnostic. For all those languages there are libraries offering functions to access the filesystem. For Lua there is LFS. But, in combination with your next point:

That the standard libs offer so little - specially table and string. I don't like inconsistency on what is provided and what not. math for example has sin and cos, but then it has foor but not round.

The biggest drawback of Lua is IMO the lack of standardized libs for stuff like filesystem access, threads, sockets and other stuff. Sure there is the de-facto standard of LFS, Lua Lanes and Luasocket, but they don't come with the standard lua distribution. Python is a very good example of how this should be done.

Related to the previous one: Lua invents its own regexp, and then bases most of its string-related stuff on it.

I don't really mind that part. I would even say that escaping control characters with % is better than escaping them with \ (i.e. %d instead of \d), because \ is already the escape character for plain strings.

.. instead of +

Please don't. Using + for both string concatenation and adding numbers makes it harder for the programmer to see what's going on. With foo .. bar you know that foo and bar are strings, but with foo + bar you have to look for what foo and bar actually are.

Other points that annoy me:

• The lack of a built in module like Perls use strict that complains every time I use variables that I have not defined anywhere. That would make hunting down typos so much easier. But of course there is a third module for just that: strict.lua
• The syntax sometimes is very verbose. I use anonymous functions a lot, and writing function() ... end every time I use one can be very tiresome.

Edit:
Also:

• Debugging Lua is PITA. I want a good (gdb-like) debugger!

[BlackBulletIV]

Other languages (C++, C, Lisp, ...) are also file-system agnostic. For all those languages there are libraries offering functions to access the filesystem. For Lua there is LFS. But, in combination with your next point:

Yeah, but C++ and C are "lower-level" languages, not high level like Lua (yes, I realise they're both technically high-level, but they're the very low of the high, so to speak), so I'd expect that from them.

As for .. vs. +, yeah, I think it's probably better to have a concatenation operator as it shows what the intent is, but I don't really mind either way.

[ivan]

[*] No bitwise operators. Very limiting when it comes to integer manipulation, such as hashing and color integer manipulation

The new version of Lua (5.2) includes a library for bitwise operations.

[Robin]

There is a lot about Lua I don't like, but most of them (for example the whole global-by-default thing) I accept because of the origins of Lua. Namely, advanced config files.

Lua is nice enough, but on the whole I prefer Python. (Although Python has its share of misfeatures as well.)

[Jasoco]

~= instead of !=, and .. instead of +

I agree with this! I have typed != so many times. I know the ! is right next to the ~, but that makes it even worse that I can't even hit the right one when it's right there. != != != is so much better. Damn you, Lua! And yes. .. sucks. I would so love to just use +. They're really the only problems I have with Lua that bug me most. I guess it's just because of my previous use of QuickBASIC.

The : operator. I would have preferred that foo.bar(baz) included foo as the first parameter of bar by default. I would not mind that the : operator was put there for the opposite case. Incidentally, I would not mind if "self" was implicit in all functions. In short: I prefer the Javascript way.

Also this I guess. Yes. This. As we found out recently.

[BlackBulletIV]

[*] No bitwise operators. Very limiting when it comes to integer manipulation, such as hashing and color integer manipulation

The new version of Lua (5.2) includes a library for bitwise operations.

This I know, it's a step forward. But I'd much prefer the actual operators, as in, ~, <<, |, and so on.

And yes. .. sucks. I would so love to just use +.

It's pretty easy to do so. I've got that functionality enabled in my strong library. Or you could just use this code:

Code: Select all

local mt = getmetatable("")
function mt.__add(a, b) return a .. b end

In fact that could actually be shortened to:

Code: Select all

getmetatable("").__add = function(a, b) return a .. b end

[miko]

[*]Lua doesn't handle directories natively. This makes using require() very frustrating, because you can't use relative paths. The fact that folders are not supported on ANSI C doesn't justify that they aren't in LUA IMHO. If you are not going to acknowledge that there's a filesystem underneath, then don't give me a require() function, and make me require stuff from C. Or at the very least, give me a require function that can be used with relative paths.

Here you go (if I understood correctly):

Code: Select all

package.path=package.path..';./my/relative/dir/?.lua'
require 'myfile'

Otherwise I agree, yet I got used to the way it is.