Hacker News Reader

Comment by nerdponx | Hacker News Reader

The main downsides of Lua are the overloaded handling of nil, and the lack of a real standard library. If it weren't for that, it'd be a pretty nice general-purpose scripting language, arguably better than Python.

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.

View on HN

> the indentation-based syntax can make for relatively verbose code in quick ad-hoc scripts.

Isn't significant indentation less verbose than Lua's use of `do ... end`?

Not if you write one-liners like

    if x < 3 then x = 3 end

I actually really like Lua's syntax, though I think a form for short Python-style lambdas would really help (short lambdas are the easiest ones to understand, so I don't see a comprehensibility objection, and Lua's grammar already makes the necessary expression-statement distinction).

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.

`if x < 3: x = 3` is valid Python, although I see your point - you could add an `else` to the Lua example but Python would require a second line.

> 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.

In this particular example, Python has the more wordy `x = 3 if x < 3 else x` which you'd rather write as `x = max(x, 3)` to demonstrate Python's muscles in terms of useful builtins.

About lambda syntax, to me it would be far more important to allow multiline lambdas than to have a shorter keyword.

> `x = max(x, 3)` to demonstrate Python's muscles in terms of useful builtins

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.

All good points. Just compare:

    (lambda x: x + 1)

    (function (x) return x + 1 end)

For arrow syntax I like this:

    ((x) -> x + 1)

but reducing the number of keyword characters from 17 to 6 is already a big win.

IUP's Cocoa port is unfinished, but there was enough complete that it was accepted into the official SVN repo.

Maybe a silly question, but isn't it possible to run Gtk applications on a Mac?

Not a Lua developer here, what is the problem with nil? Just curious.

It's not that nil itself is a problem, the real issue is that every invalid table key access doesn't trigger an exception (like Python), but instead returns nil. And everything in Lua is built with tables (including whole class systems), so this makes debugging a serious pain in the ass.

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.

Nil serves as non-existence, so cannot be used as a normal value. You can’t have a table (an object/struct in other languages) that has “existing” nil-valued key, so it breaks json schemas. You can’t have an array that contains nil, because arrays are defined to be continuous tables if consecutive indices that do not have nil. #-operator may return either 3 or 1 for {1, nil, 1} array. You delete keys and last array values by setting to nil. People tried to introduce special NIL values (an globally-available table with clear testable indication of its purpose), but it never becomes a standard and as a result every lib that requires it uses it’s own.

Couldn't you just use `false`? I was pretty opposed to the talk of adding an "undefined" value in the discussion prior to 5.4. As someone who has to write javascript fairly often having a large number of falsey values is definitely not something to be desired. I think in older versions of Lua there was a pattern to include an `n` field in your tables to keep track of it's length. Lua is all about "mechanisms over policy" and provides many ways to create tables that behave like arrays in Lua.

You're right, Javascript's undefined creates a whole new set of problems that you don't want to deal with, at least Lua didn't make that mistake.

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?

I actually like having both "nil" and "undefined" in Javascript!

"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.

Right, and it allows for arguments of functions and destructurizers to be undefined for default and null for null. Absent and empty are really different concepts. These being merged, separate, implicit or explicit, all may be hard to manage, but at least in the case of (undefined & null) it is a most uncrippled value system. JSON also got it right, allowing null but not undefined. At the end of the day all that matters is a programmer’s convenience. Corner cases exist everywhere.

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

Another related issue with Lua is:

  table.insert(t, string.gsub(s, “1”, “2”))
  -- happy debugging

It is full of these little design decisions that put your feet to danger not any less than others.

It would be nice if "undefined" consistently meant absence, but it's not quite that:

   console.log('foo' in {foo: undefined}); // true!

Reply on news.ycombinator.com