Hacker News Reader

Comment by Pxtl | Hacker News Reader

... that is the strangest collection of complaints I've ever seen about Lua. He obsesses over minor syntactic quibbles like the lack of a += operator and the ~= and "not" instead of C's inexplicable exclamation marks (how does this man stand SQL?) but he doesn't dwell on Lua's bigger flaws.

I mean, 1-based arrays, weird scoping and the pairs/ipairs thing seems far more serious than the lack of a proper conditional operator (how long did Python go before it got a conditional operator?)

Lua is everything it was meant to be - a lightweight, user-friendly, safe language that runs nice and fast in spite of being very hashtable-oriented. There's a good reason it's heavily used as a scripting language for game engines and other platforms that need to let users run code provided by other users - a more "batteries-included" language would have users wiping each other's filesystems.

View on HN

What's bad about pairs/ipairs? They're just iterators, and they make the "generic for" construct much more versatile. The standard library also includes two more iterators, string.gmatch() and io.lines(), which are pretty handy. I've also used iterators to implement streams (or "lazy seqs", if you will) and something akin to Python's range().

I find nothing weird about lexical scope and the 1-based arrays don't bother me at all, but iterators are awesome.

To me, Lua's most annoying feature is that tables are the only data structure. When I was first learning Lua, I thought it was pretty cool to have one and only one very versatile data structure. Nowadays, I find it's more trouble than it's worth. Indeed, the fact that pairs() and ipairs() are separate functions demonstrates that tables are a leaky abstraction: you have to constantly think about whether a table represents a hashmap or an array or both. Luckily, Lua is very extensible and there are several ways around it.

All in all, I find Lua to be an excellent language. I wrote a utility in it at work, and most of the veterans started sweating when I told them it was written in some language they'd never heard of. As soon as I showed them the code, they were visibly relieved. "We can read this and understand it," they said. Lua's readability is a big win.

To me, this harkens back to the debate about the length of a table if it has nils in it.

The Lua table is not the be-all and end-all of data structures (though it is quite versatile out of the box). However, it can be the basis for any kind of data structure you can imagine. Trees of all varieties, priority queues, etc.. The strength of the language is that there is just one fundamental data structure, and it is implemented well, and it has good syntax support in the language. There is no mental overhead like with Python where you have to use square brackets for lists and curly braces for dictionaries.

> There is no mental overhead like with Python where you have to use square brackets for lists and curly braces for dictionaries.

Seriously?

He forgot to mention objects, which are also almost-dicts in python, but with a ton of magic rules like slots and methods storing their object when assigned and whatnot.

Lua has pretty nice and lightweight prototype OOP, which boils down to a few uses of : instead of . on tables and setting the __index of the metatable to be the parent table.

That's not to say python is not an excellent language, just that lua is a lot simpler.

0-based: you're offsetting. In C, you're offsetting a base address by a multiple of sizeof(item).

1-based: you're numbering. In Lua, an array is an optimization of a hash, and the items inserted without explicit keys are numbered one, two, three…

1 based indices are fine most of the time, they are mostly like 0 based yet start at 1 :) When it does become a problem is when you are reading and using binary formats and offsets, where I seem to always get off by one errors. A ternary function, iff, is soo simple to implement Lua. Scoping is just something you have to understand as with tables there is no problem with them besides a beginners understanding of them.

What you consider a minor gripe, compound assignment operator, I personally think is a flaw in the language same goes for bitwise functions instead of operators. Here is an example I posted earlier on twitter.

object = object + other

"object" and "other" here are full userdata and the code is going to malloc a new userdata and also create a new object in C/C++; which is straight away going to over write the original instance. Huh? why? += makes so much sense.

Each to there own, I can fix my issues using patches but it would be nice if I did not have to.

I have started just using iterators for stuff that starts at 0.

Might I ask, how would you implement a ternary function that should retain the lazy evaluation quality of the syntactic ternary operator?

Lua at present has full lexical scoping. Lexical scope is not "weird"; it's correct. All mainstream languages with higher-order functionality that aren't Python use lexical scope, and for good reason. It can be difficult to implement, but it's intuitive.

Welcome to HN where the top-rated comment is from someone who admits they didn't read the presentation, doesn't understand what the author was saying and manages to complain.

Brevity.

I had the same initial impression, but he actually goes over and mentions how much he ended up liking Lua.

I dare to say that Lua is everything that javascript is trying to be.

Will you please stop it with the array thing? Lua has no arrays... it has tables. You can use a zero index if you so please, and no one can stop you.

This is a silly thing to say. Here, let's try to write some code using 1-based indexing:

  t = {foo()}

And now with 0-based indexing:

  function capture_values_internal(idx,t,remaining,val,...)
    if remaining == 0 then
      return t
    else
      t[idx]=val
      return capture_values_internal(idx+1,t,remaining-1,...)
    end
  end
  
  function capture_values(...)
    return capture_values_internal(0,{},select("#",...),...)
  end
  
  t = capture_values(foo())

  function capture_values(...)
    local n,t=select("#",...),{...}
    for i=0,n do
      t[i]=t[i+1]
    end
    return t
  end
  
  t = capture_values(foo())

Gosh, that was easy, I can't wait to use 0-based indexing throughout my program.

He does talk about arrays on slide 25 and the last slide is about the problem of global scope.

Ah. I stopped reading when wading through the ocean of performance comparisons.

Good points. As I was reading it, I wondered if there was some satire in the complaints. I didn't know the author's context, so I thought, "Maybe these are minor complaints from someone who famously loves the language."

> I mean, 1-based arrays, weird scoping and the pairs/ipairs thing seems far more serious than the lack of a proper conditional operator (how long did Python go before it got a conditional operator?)

No. Not having a real numeric or array type is serious, '1-based arrays' is just a minor quibble about syntactic sugar.

LuaJIT has real types and arrays, as part of the ffi.

The language seems to ship with an array type and a numeric type. I hear it will soon ship with 2 numeric types instead. If you aren't satisfied with your ability to redefine the numeric type(s) to literally anything by changing 1 line in 1 header file, you can use a userdata that supports "real numeric" operations.

Reply on news.ycombinator.com