As someone who chose the Lua runtime as a basis for his own toy language, these are my observations:

A. True. Paradoxically Lua's source is well-documented in places that arguably didn't need documentation in the first place, but it tends to contain no comments whatsoever in tricky places like the VM or the implementation of internal data objects.

B. Global-by-default has bugged me as well. Thankfully it's not difficult to patch it so declarations are mandatory and local though.

C. It's a matter of taste in the end. I struggled for a while on whether to convert it to 0-based indexing or not, but so far have left things as they are. Depending on your programming style, you might end up not using indexes directly all that much.

D. The distinction between having separate array and hash parts in a table kind-of works, but only if you make the conscious decision never to work with numerical indexes. Generally, I think this type of array/map hybrid is something PHP got right with their ordered hash maps, whereas Lua's way of doing things have a few gotchas.

[] For a lot of applications, having only one number type works surprisingly well. I just wish they had opted for morphing the internal number representation according to usage in the script, instead they are now doing a separate int type in Lua 5.3 which feels a little out of place for my taste.

[] I really don't think Lua needs a separate symbol type.

[] Things I didn't like include how often you have to check for certain conditions in Lua to avoid raising fatal errors. Not being able to use keywords inside the table dot notation. The idea that the self operator works on a function in the table instead of its metatable. The lacking core library, especially when it comes to table usage. The fact that a require()'d file doesn't know its own file name. No default to-string serialization on tables. The pattern that control flow statements always require code block components instead of single expressions. Goto statements.

Here's a link to my project which addresses my personal Lua pain points: http://np-lang.org/

Hey Udo, so you're around a computer... Any reason you haven't reached out in over a month?

Hey, I'm back. Emails are going out soon.

You should have a look at Squirrel (http://www.squirrel-lang.org/) - it addresses most of the points above but is still very lightweight and easy to embed. The main disadvantage is that the documentation and community is not as well developed as Lua.

Variables being global by default is definitely a wart. You can mitigate it a lot with a linter or with runtime tests (extending the global metatable). Local by default would be a bad idea and worse than global by default, IMO, as it would mess up lexical scoping. The ideal would be having a compilation error by default.

It would be fine, I think. Just create the variable in the scope you want it, then assign to it somewhere else. If you get it wrong, you get it wrong, and there's scope for weird bugs from that - but the effect is at least localized, lexically.

(Of course, the right thing to do is have explicit variable declarations...)

Localized bugs are still bugs. Better always require a variable declaration and have no defaults.

Usually languages use local-by-default to avoid the need for variable declarations in the first place (in misguided manner, IMO) instead of doing so to avoid globals.

This page might be interesting, btw: http://lua-users.org/wiki/LocalByDefault

>>a style that was pretty alien to me.

There is your real problem.

A. C is a beautiful language. I believe a more productive attitude towards any usage of C - as a binding/engine language layer, or whatever - is to assume: there is no one familiar style. (What Lua/src has, is good coding rules compliance..)

B. You control the VM, completely. The Lua language is designed with the VM integrator in mind. Lua frameworks are not something you inherit. So .. Why does global name-spacing versus local definition bother you? Show me your offensive global/local case; in every single case, it can be solved with better design. At the very least, walk _G yourself.

C/D. Its the 21-st Century, 1-based indexing makes sense to most of the non-hacker world, since you can't have a "0-th" box in which to store things in the real world. Except of course you can, you just make one and label it, arbitrarily, the '0' box .. in fact you do have the ability to index everything 0-based yourself in Lua, so have at it. Lua provides the 'one-type to rule all things' type, the Lua table{}, to give you the options you need. Want an array? Use your new_array{} as an array. Want a string-dictionary? Have at it. Need a hash: ditto. Bonus points: understand what you're doing, and get features from the table type; like scatter detection, packing/indexing/ordering operations, and so on. Lua metatables are your friend, not an enemy. Learn to use the table type and you will become a convert.

E. C-side API. You do have to understand the design constraints of the VM. That's about all you have to do. Is that really so weird?

Oh, don't worry, nobody will change their opinion because of me, nor would I expect it ;)

Zero based indexing doesn't make any sense. You start counting at one, not zero. It causes confusion.

Lua's universal tables also simplify things and aren't that less efficient.

> Zero based indexing doesn't make any sense.

Ordinal and cardinal are different. There's nothing left to debate.

(Also, time to start a petition to move the 0 key to be before the 1 key on the standard keyboard layout ;)

Arrays start at zero because what you're counting is how far you're moving a pointer from the initial address in memory, not the items themselves. Array[0] is literally 'read what's at pointer sizeof(n)+0 from the start.' Zero-based indices make perfect sense when you know what they actually indicate.

Although to be fair, starting with one and actually counting the items makes sense too, and seems more intuitive, and this may not even apply to Lua at all. But one-based indexing is still wrong regardless.

a) it doesn't matter b) lua doesn't have these pointer things you speak of. If you are going to hate on 1 based indexing at least have the fine style of EWD.

Off by one errors are enough of a problem without having to remember that lua decided [1] means something other than what [1] means in almost every other language, so plan accordingly.

It's not critical, but it does matter.

c) the audience. Lua was designed a scripting and data environment to run simulations in Fortran. So the customer was already using 1 based indexing.

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

Well... Fortran sucks.

local-by-default has serious problems.

It is routinely discussed in the Lua mailing list. Here are some pointers about it:

http://lua-users.org/wiki/LocalByDefault

What's the symbol type for, and is Lua incapable of expressing it?

Symbol types[1] are useful for storing identifiers, method names or enums. They are common in LISPs and in Lua you use (immutable) strings for a similar purpose[2].

The main advantage of symbol types are that they have a more restricted API than strings and that they might be more efficient (integer vs string representation)

[1] https://en.wikipedia.org/wiki/Symbol_%28Lisp%29

[2] For example, in Lua obj.foo is syntactic sugar for obj["foo"], similarly to Javascript.

Since you pointed out that Lua strings are immutable you're aware of what I'm about to say, but just to make it explicit:

The efficiency argument is a common one for symbols in general, but in Lua it doesn't really hold because string comparison has constant cost (ie, it's a simple pointer test, since strings are immutable).

Immutable and interned!

(This may or may not be an issue, but it still offended me somewhat, since you're getting all of the compile-time cost at runtime, combined with none of the expressiveness. Not a tradeoff that impresses me, personally, even if the speed is fine - but it takes all sorts.)