Lua Criticism Is Unwarranted

Re:Lua Criticism Is Unwarranted by srhtftw on Thursday October 26, 2023 @03:43PM (#38030778)

I had the pleasure of working with Lua 5.1 back in the late noughties. For me it replaced Tcl whenever I wanted something I could configure above a C library. At the time I used it I found it quite nice but I'll also not forget the hours I wasted tracking down nil table corruptions which could have easily been caught by a type checker.

I had some hope that Luau https://luau-lang.org or Teal https://github.com/teal-language/tl would make things better but with the following example

    function foo(x: number): string 
      if x == 2 then return nil else return "foo" end
    end
    
    x = { foo(1), foo(2), foo(3) }
    
    for i,v in ipairs(x) do
     print(i,v)
    end

they produce no warning and sadly only print

    1 foo

When I was younger I might have put up with that sort of WTF but now that I have better options I try to stick to type checked languages where I don't have to.

[ Parent | on HN ]

Re:Lua Criticism Is Unwarranted by caligian on Thursday October 26, 2023 @09:36PM (#38033716)

This is one of the things i was talking about. You cannot map nil to a key because nil means absence. The compiler can only infer such absence at a control flow level aka passing arguments to functions or checking nil-variables. You are supposed to use false in such a case here

[ Parent | on HN ]

Re:Lua Criticism Is Unwarranted by srhtftw on Thursday October 26, 2023 @10:46PM (#38034116)

To me this is a serious flaw and I simply refuse to accept that it's beyond criticism. No language should allow its collections to be corrupted this easily. Especially when a key use of the language is configuring other software.

Fortunately there are other configuration languages available now besides Lua which provide type checking, so I remain hopeful that a future version of Lua or one of the newer typed Lua variants will eventually learn from those.

[ Parent | on HN ]

Re:Lua Criticism Is Unwarranted by caligian on Saturday November 04, 2023 @11:15PM (#38147728)

There is no 'corruption' happening anywhere.

When you register local variables, they are merely defined as register locations and have a default value of nil which is absence and hence memory saved. They would have to mark nil explicity as a new data structure which is probably wastage as they would have to allocate memory for every variable declaration that may or may not be used.

It is just nil, nil at a literal level with the exception being local variables which are handled differently as offsets to register locations than other dynamic languages without such 'local' qualifiers.

[ Parent | on HN ]

Re:Lua Criticism Is Unwarranted by cxr on Monday November 06, 2023 @01:47PM (#38166909)

> I found it quite nice but I'll also not forget the hours I wasted tracking down nil table corruptions which could have easily been caught by a type checker.

> I had some hope that Luau https://luau-lang.org or Teal https://github.com/teal-language/tl would make things better

Inline type annotations are not a prerequisite for typechecking; there's nothing stopping you from writing straight Lua (or whatever) and then having a separate tool that does typechecking _without_ having to change the language. People are failing to take away the most important lessons from TypeScript.

The same goes, frankly, for languages that ostensibly have typechecking but have such deficient type systems that it's not exactly that much better than not having one. (Like C, for example.) Considering that type annotations are more valued for being a form of documentation than they are valued for making it easier to write the compiler's code generator...

If you have a function like printf that is ostensibly typechecked but not really, and you already have documentation (like man pages) for that function that says that the arguments need to be such-and-such, but the typechecker for your compiler/IDE isn't able to factor that in at or before build time, then that's a compiler/IDE problem, not anything that necessitates a change to the original grammar.

[ Parent | on HN ]