On: What I think about Lua after shipping a project wi...

[vaylian]

> Maybe i should have known better than to ask about things I dont know.

It is fine to not know things. But when I look at your post, I see that you didn't ask any question. You only made statements that were based on very unfounded assumptions.

But to get back to what tables are: They are key-value pairs with both array- and hashmap-semantics. By convention, arrays start at 1 in Lua. They are very similar to dictionaries in Python , associative arrays in JavaScript and other key-value data structures in other programming languages. However, lua also uses them for storing variables in environments (some people would call environment "scopes") and there are special callbacks for missing variables and accessor functions when working with these tables.

[zdragnar → vaylian]

> associative arrays in JavaScript

You're thinking PHP. Arrays and objects are discrete things in JavaScript. You can add random properties to arrays (since they are also objects) but don't expect them to behave well when doing things line loops, getting they length, etc.

[int_19h → zdragnar]

JS objects are associative arrays with some fluff on top.

[zdragnar → int_19h]

They really aren't. Tacking random properties onto an array doesn't affect the array's length, they won't show up when using `forEach`, map, reduce, filter, or any of the other built in functions.

[int_19h → zdragnar]

I was talking about JS `Object`, which is an associative array (note the lower case "a" here; I'm not referring to JS `Array` objects!). You can do:

   obj = {}
   obj.foo = 1;
   obj["foo"] = 2; // overwrites above

which is exactly like Lua, even down to syntax in this case:

   table = {}
   table.foo = 1
   table["foo"] = 2  # overwrites above

etc. This is ipso facto what an associative array is - a mapping of keys to values. The only difference between JS and Lua in this regard is that in JS, object keys are always strings, while in Lua they can be of any type except `nil`. So obj[1] is the same as obj["1"], but table[1] is distinct from table["1"]. However, that does not change the fundamental semantics of the data structure in question - `Object` is still mapping arbitrary (if type-constrained) keys to values, so it's still an associative array by definition. Back when JS didn't have a dedicated `Map` type, it was often used as such in practice, too.

I will also note that things like length and iteration can be defined in many different ways. E.g. the way Lua defines length (operator #) for tables - which are also associative arrays, of course - excludes non-numeric keys. And for-loop does not directly work over tables, so how you iterate depends on which iterator function you use - `for index, value in ipairs(table)` will also only iterate over numeric keys, while `for key, value in pairs(table)` will iterate over all of them. That, again, does not change the nature of the data structure in question.

[fifilura → vaylian]

Yeah I forgot a question mark.

[fifilura → fifilura]

So it seems like what they call tables are in fact maps or dicts. "Symbol tables".

I initially raised my eyebrows since what actual tables would have brought would be joins on non unique keys and multiple columns.

That would have unlocked more versatile "table programming" as in SQL, pandas, R and to some degree Excel.

The real benefit of "table programming" is that it is default distributable. All operations are atomic and immutable.

(I also lost some interest in Lua after -4 downvotes).