I'd like to think that I'd rather have Lua as a language, with Python's class definitions and Python's ecosystem. What I mean by Lua as a language is the interpreter - and luajit - but also its `local` variables and scoping rules (Python's rules are rather strange, which the nonlocal keyword signals clearly).
Questions for the Lua critics. How many Python modules, e.g., in C, have you written. Which language is easier to write modules for, Lua or Python. Ever compare the startup time of the Lua interpreter to the Python one. What s the tally of applications that have embedded Lua interpreters versus those that have embdedded Python ones.
Because it is (optionally) embedded in applications I use every day and/or rely on, whether it's a DNS load balancer, a TCP/HTTP proxy server or a fast OS kernel, I always use Lua for "practical purposes".
Python seems to have development team of millions, but would I rather have a smaller interpreter with faster startup that is easier to write modules for. To me, that is an important question. Will I ever write Python modules in C for own use, or will I have to choose someone else's library and become 100% reliant on it. Does that limit the true "DIY" potential of Python vis-a-vis Lua.
At least the parent did not use the "indices start at one" justification for concluding Lua is inferior. In the early days of Lua, that was a red flag to me that this language must be good, if that s the best criticism anyone could come up with.
static int l_foo(lua_State *L) {
size_t len;
const char *s = luaL_checkstring(L, 1, &len);
luaL_newuserdata(…);
return 1;
}
luaL_register(…);
As of nil, “:/.” and others like local…in, table=array, it just becomes an always-itching scratch after years. Lua doesn’t even respect full backwards compatibility (not that it was claimed) but its authors stick to the principles that many folks tried to un-convince them to no avail.
language must be good, if that s the best criticism anyone could come up with
That’s only the shallow surface, the real talk always goes in the mailing list before the release.
And of course you could always just write functions in Lua and call them from C.
If you need C modules for Python, use Cython for the binding, don't write them "from scratch".
I probably disagree with 90% of the criticisms leveled against Python, but it definitely is slow in "loopy" tasks, and the indentation-based syntax can make for relatively verbose code in quick ad-hoc scripts. I'd be plenty happy using Lua instead, if only it had a more thorough standard library. The nil-handling thing is annoying, but fine enough for quick scripts.
Isn't significant indentation less verbose than Lua's use of `do ... end`?
if x < 3 then x = 3 end
The Lua ecosystem was seriously damaged by the 5.1>5.2 split for a while since LuaJIT (hence Torch/nginx) and LÖVE both basically stayed with 5.1 and those were major projects that drew people to the language. The other cool unique thing in the Lua ecosystem, the native-widget (Windows/Gtk) IUP toolkit, remains barely known about and never ported to OS X, possibly due to a lack of Mac users in Brazil. Hence the "language without an ecosystem": it didn't happen for no reason, though the willingness to make breaking changes is a reason the language became so popular in the first place.
NB. IUP is still around, but it still doesn't have a Cocoa port.
> a form for short Python-style lambdas would really help
Interesting - many in the Python community feel that its lambdas (particularly the use of `lambda` as a keyword) are too verbose and would prefer something like `x => x+1`. Maybe such an arrow-function syntax is achievable with Python's new PEG parser - I'm fairly sure it couldn't have been supported by the old LL(1) parser.
About lambda syntax, to me it would be far more important to allow multiline lambdas than to have a shorter keyword.
Even Lua has a built-in `math.max` function that works with integers. Maybe it’s Lua’s way of flexing on Go :)
> About lambda syntax, to me it would be far more important to allow multiline lambdas than to have a shorter keyword.
Never going to happen, unfortunately. It’s just not possible within the fundamental rules of Python’s grammar: that statements use significant indentation and expressions do not.
(lambda x: x + 1)
(function (x) return x + 1 end)
((x) -> x + 1)
In fact, even global variable accesses are designed to work as table accesses to _G (the global table), so if you make a typo then the interpreter doesn't say that you've mispelled a variable but instead silently gives you nil. This leads to all sorts of weird bugs that are very hard to track down. Probably the number one reason why I ditched the language for something else.
But using False for invalid key accesses seems to be a really bad idea. Sometimes you need to store boolean values in tables. When that table access returns False then you don't have a way to tell if it was from a successful key retrieval or not. (Lua solves this dillema by making that storing nil in a table is just as if nothing really happened, which is pretty reasonable)
If Lua had a more fleshed-out exception system (The current one based on pcall() is a bit limited both in syntax and functionality), I think it would have been better to go for the Python route (throw exceptions for invalid table access). Don't know how it will take a toll on performance though, maybe that's the reason why it chose such a simplistic route for implementing tables?
"Absence of value" is different from "data that happens to be some kind of empty data point".
Also part of the issue is function arguments, there's no arity-checking by default.
With all flaws of js, this is where it shines:
var t = undefined
var u = {b:1}
var {a=42, b=true} = {undefined, …t, …u}
// a==42, b==1
table.insert(t, string.gsub(s, “1”, “2”))
-- happy debugging
console.log('foo' in {foo: undefined}); // true!