Why? I've worked with Lua before and to me it's not a bad language, but nothing special either. I'm honestly wondering.
Why? I've worked with Lua before and to me it's not a bad language, but nothing special either. I'm honestly wondering.
I think Lua is a bit unique in this for two reasons. First, they have in intentional open-source but not open development model. Second, because of the way that Lua is embedded inside other projects, there is more willingness to implement backwards-incompatable changes. I'm sure this is a negative for some who want to build a larger, less fractured community, but it has advantages for language cohesiveness.
You’re given a small set of tools and it’s incredibly easy to build off them.
the one confusing element - one-based indexing of arrays! that is something i found hard to adjust, as it makes off-by-one errors more prominent...
but otherwise it's a nice language.
But that said, I'd prefer that Lua had 0-based indexes, simply because that's what most other languages have, not because it's superior.
unless you can exclusively program in 1 language only, these confusions would be the cause of various bugs, or at least, increase the cognitive load. Programming is already hard enough, without artificially increasing the cognitive load!
This is not necessarily a bad choice. Exceptions and such can be a real pain. However, accidentally getting a null value because you didn't check and then have it propagate much further in your program is extremely difficult to debug. Instead of blowing up at the site of the bad lookup, you only see the distant effects of it (e.g. put the null value into another table, which gets put in another table, and then is attempted to be called as a function, etc).
It’s pretty unfortunate. You can mitigate it using meta tables though.
> t = {}
> t['a'] = nil
> t['a']
nil
> t['b']
nilAgreed that interaction with C or other 0-based languages or systems (eg screen coords) makes things more difficult.
Probably someone else can shed light on exact numbers, but Lua is faster than Python.
Folks who sniff at putting a scripted/interpreted language into an embedded environment really need to think twice with Lua. It is fast, tight and highly performant - and if you bundle it along with LuaJIT and Turbo.lua, it'll give you the best of all worlds - aynsc i/o, coroutines, very, very fast performance and a great execution environment upon which to build truly useful apps.
That's usually what people like about Lua: it's barebone, yet high level and clean.
If one likes Python, then the chance of liking Lua are low.
E.G:
Both python and lua can open something (a file, a socket, a transaction...) in one line.
But only Python has the `with` construct that means it's easy to guaranty you close it in case of an error.
Lua is then easier to learn: one less concept to master. But the high level tool of Python, that you had to learn, make your life easier.
They have very different trade off.
I don't know. I quite like both as well. The design ethos feels similar although Python has certainly added more features over the years.
Python was always chock-full of advanced features, people just usually don't notice because they get productive in 3 days with the basic features and don't need to go further. It's has the quality of a very smooth learning curve, but a very long one if you care.
Unkike the __gc hook which provides no guarantee as to when it will be called, if ever, the __close hook is called when a value goes out of scope.