lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 1/22/2018 12:54 AM, Elias Hogstvedt wrote:
While this thread has altered my views on the issue a bit, I'm also starting to wonder if I'm just bored and looking for change.

Another bias I have that I should have mentioned is that I'm using LuaJIT (5.1~2) heavily with FFI so I'm also also seeing this as a future performance benefit. Perhaps it would only help LuaJIT to be a bit more predictable but not PUC Lua so much.

I read Dibyendu posts, they are very useful; eventually if one goes looking for performance, we will prefer or need certain things. But JIT is not one of Lua's design priority. If I wanted pedal-to-the-metal performance, I would make wholesale changes, no question.

It's the same with JavaScript. We threw metric truckloads of resources at it over the years, and amazing JIT implementations have been made. But not close enough to metal. asm.js pops up, then in comes WebAssembly. The dynamism of scripting languages is being steadily being eclipsed by the desire for performance. Maybe everything will end up moving to the kind of scheme we use for GPUs.

Compare stock Lua with these tech, plus a benchmarking culture, of course it will look dowdy. What chance does Lua have when compared to things backed by enormous amounts of resources? Lua is not going to win these kinds of performance benchmarks, but it will still perform very well for a dynamic, scripting language. At some point, it will cease being an apples-to-apples comparison. Which is the 'right' kind of scripting language? They are all good, for their target objectives.

I'd like to create my own language as well with my own ideas. Perhaps I'll learn a thing or two as to why certain desicions are made.

Here is another perspective on tables with more accessible wording: Many of us have been 'trained' using standard data structures coursework material. In a way everybody does think arrays and hashes separately -- I think of them separately when using other languages. But that does not short-circuit my brain when I switch mental modes to coding Lua.

Lua is scripting language, it is more dynamic and malleable than say, compiled languages or languages targeted towards JIT. Lua tables simply sits at a higher abstraction than traditional data structures. That's why I always think of the word 'lookup'. The data structures coursework, those are more at a for-compilation abstraction level (notably, with examples in C/C++/Java.)

Let's say, I have an idea of generational tables. So I implement tables using red-black trees as a back-end option to get always-sorted tables and a no-op when sorting the table. It doesn't change the abstraction that is the Lua table. But well, the table abstraction may not be the ideal thing if one wants (or expects) everything to be boiled down to run in lean and mean machine code close to metal.

On Sun, Jan 21, 2018 at 5:24 PM, Andrew Starks wrote:

    Top posting to nobody in particular.

    I was arguing something about lengths or arrays at some point.
    Some helpful Lua List member kindly pointed something out to me:

    Lua does not have sequences. It only has tables.

    To put a positive spin on it: Lua has tables as it’s only data
    structure, at least as of 5.4, which will eliminate the
    limited ... (perhaps helped along by threads like this).

    There is nothing that can’t be represented as a table and if
    you want something fancy, you have userdata. Adding sequences
    solves no problems.

    “One data structure” is one of Lucas most important traits. I
    recommend learning to enjoy it and to play with that beautiful


    On Sun, Jan 21, 2018 at 06:15 Petri Häkkinen wrote:

        On 21 Jan 2018, at 12.33, Elias Hogstvedt wrote:

            I don’t get it. Where’s the ambiguity in e. g. { 1,
            2, 3, type = ”int16” } ?

        I would say it's ambiguous because I'm not sure if this
        is "safe" to do. I've personally never done this and
        would put a new table inside the table to hold the
        numbers. If this has no side effects then it's more or
        less a shortcut for {array = {1, 2, 3}, type = "int16"}

        It’s totally safe and there’s a similar example in
        Programming in Lua. Section 3.6 in the 2nd edition (I
        don’t have the latest edition yet):

        polyline = { color=”blue”, thickness=2, npoints=4,
           {x=0, y=0},
           {x=-10, y=0}
           {x=-10, y=1}
           {x=0, y=1}

        Produces less garbage because there’s no intermediate
        table to hold the coordinates array.


Kein-Hong Man (esq.)
Selangor, Malaysia