7 ms·

#lang Lua

101 points by Bogdanp 4y ago

armchairhacker 4y ago
Implementing Lua is a great way to test out your language-generating program, since Lua is an extremely simple yet popular language. CLISP or Scheme is also a great test language...though Racket already has that covered. It would be interesting to see someone implement a language like Python, C (interpreted or compiled to ASM), or Java in Racket. But it would also be an insane amount of work, probably to the point where you're almost just re-implementing the language, and I also wonder if Racket would get really slow or crash due to all of the complexity.
- jmclnx 4y ago
  And NetBSD has a hook to the kernel via lua https://man.netbsd.org/lua.4 https://man.netbsd.org/lua.4
  - TedDoesntTalk 4y ago
    This is both insane and cool.
  - canadianfella 4y ago
- spdegabrielle 4y ago
  Python and Java have been implemented in Racket. I believe implementing a subset of Python was also an assignment for some course. There is `#lang c` for writing C programs in DrRacket but it uses the installed C compiler, rather than re-implementing C in Racket. https://docs.racket-lang.org/c/ https://docs.racket-lang.org/c/
PenguinCoder 4y ago
Lua is a great language, simple enough to start with and do something with. Lightweight and fast. I love using Lua even though I hate having to reinvent every library worth of functions I constantly want to use elsewhere. Lua rocks is okay but I don't really like using it. Lua has a Simple syntax, easy to grasp but hard to master and achieve complexity with.
- gyulai 4y ago
  I suppose the more lua-esque thing to do is to not use lua in isolation and not rely on lua rocks, but instead embed it in some host language, and then rely on the host language to do the heavylifting where libraries and ecosystem are concerned. For example, if you're scripting and need to deal with yaml files, then instead of using a yaml parser from lua rocks, you might embed lua in python through lupa and then expose PyYAML through lupa to your lua code. This sounds limiting, but it's actually liberating. Depending on what it is you're actually doing, you can just pick the host language and the libraries you want to use in a way that best integrates with the things you need to integrate with.
  - maccard 4y ago
    > then instead of using a yaml parser from lua rocks, you might embed lua in python through lupa and then expose PyYAML through lupa to your lua code. Well this might take the cake for the most bizarre suggestion I read online this weekend. If someone on my team genuinely suggested embedding an interpreted language inside another interpreted language that we have embedded in a static language, just to load config files, I would genuinely think they're totally out of touch.
    - gyulai 4y ago
      "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize." [1] Embedding python in something else was not part of my suggestion, rather I suggested using python in cases like scripting, where python would already be a good choice of an ecosystem. Also YAML-parsing was merely an example, and I wasn't necessarily envisioning that parsing a config file was the only actual purpose it would serve. The fact is that no piece of code ever exists in a vacuum. It's always part of some application ecosystem, e.g. Windows GUI programming in C#, apache spark based ETL development in Java, scientific computation in Python, etc. ...most applications have an ecosystem (language+libraries) that's a clear "winner" in terms of adoption and richness of functionality for the given application. My suggestion is merely this: Just go with the flow, pick the winning ecosystem, then embed lua and write your own stuff in lua while exposing whatever bits of ecosystem you need to integrate with to lua through some minimal logic that exists on the host language side. If you context-switch at any point in the future, that gives you a good chance of being able to reuse your lua code. For example say you've developed some highly specialized piece of math for a scientific data crunching project in Python. Now you want to use that math in a GUI. Just embed lua in a host environment that's good for GUI development. ...chances are you'll be able to reuse that Lua code. If you had written the math library in Python to begin with, you're now in the difficult situation of being forced to use Python for GUI development, embedding Python in something that's good for GUI development, rewriting your code, all of which are pretty bad options and Lua might be a lesser evil. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
andrewmcwatters 4y ago
Bogdan, not sure if this interests you since you've already commented on your approach in the article, but at Planimeter we use some utility scripts based on some comments at StackOverflow by Jonathan Leffler that help autogen LuaJIT FFI bindings. We started the luajit-ffi-bindings[1] tag at GitHub. If you're ever interested in their practical usage, Google me and let me know. [1]: https://github.com/topics/luajit-ffi-bindings https://github.com/topics/luajit-ffi-bindings
- andrewmcwatters 4y ago
  https://github.com/Planimeter/lffiutils https://github.com/Planimeter/lffiutils
gus_massa 4y ago
> a couple things are still missing lexer support (long brackets, scientific notation for numbers) How much of the standard Lua test suit can your implementation pass? Do you have some benchmarks to compare the speed? What is the problem with scientific notation? Racket can parse floating point numbers, including some weird cases [1], but I guess Lua has a slightly different set of weird cases. [1] From https://news.ycombinator.com/item?id=15628989 https://news.ycombinator.com/item?id=15628989 > Eli Barzley pointed out that Racket[BC] reads #e#x+e#s+e-e#l-e as a number.
- Bogdanp 4y ago
  > How much of the standard Lua test suit can your implementation pass? I haven't tried it yet, but I don't believe it would get very far since I haven't yet exposed ways to load Lua code from Lua modules (`dofile`, `load`, `require`, etc.). I've been building up my own test suite[1] while working through the reference manual[2]. I had never really used Lua before this, so it's been pretty interesting learning the language while implementing it. > Do you have some benchmarks to compare the speed? I've been using programs from the benchmarks game[3] and comparing them against regular Lua on my machine. On these programs, the overhead is usually somewhere around 2-3x. I believe that's mostly because these programs tend to be very mutation heavy. It's also possible that the way I'm compiling things down to Racket is defeating optimizations, but I haven't yet dug in. If you're curious, you can get it to print the code it generates for any given module by setting the `RACKET_LUA_DEBUG` env var to `x` before running some code. Eg: $ echo -e '#lang lua\nprint(1)' > test.lua $ env RACKET_LUA_DEBUG=x racket test.lua <<test.lua>> '((#%provide #%chunk) (#%define _ENV (#%global)) (#%load-stdlib! _ENV) (#%define (#%lua-module . #%rest) (#%begin (#%begin (print 1)) (#%values))) (#%define #%chunk (#%adjust (#%lua-module)))) 1 > What is the problem with scientific notation? Racket can parse floating point numbers, including some weird cases [1], but I guess Lua has a slightly different set of weird cases. Yup. I just haven't gotten around to it. My goal this week has been to get it to a usable spot for embedding in my app and then iterate from there. [1]: https://github.com/Bogdanp/racket-lua/tree/master/lua-test/lua/examples https://github.com/Bogdanp/racket-lua/tree/master/lua-test/l... [2]: https://www.lua.org/manual/5.4/manual.html https://www.lua.org/manual/5.4/manual.html [3]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/
felipelalli 4y ago
Good job!
gyulai 4y ago
I feel the need to ramble slightly OT on how great Lua is: I was looking for an architecture/tech stack recently that would allow me to develop a cross-platform desktop GUI. I went on a several-weeks-long fact finding mission (the longest of its kind I've ever done in my 10 years as a professional software developer). The option that won was to write all business logic (a few thousand lines of code) in Lua, then write the GUI in each platform's native language+ui-library combination and re-use the same business logic by embedding Lua. Another option that made the shortlist was using Haxe instead of Lua, but after several weeks of active Haxe development, it became clear that that was a bad idea, and with Lua, the developer experience is now so much better. I definitely plan on continuing to use Lua as my main programming language. This comes after 20 years of having python as my main programming language because I'm displeased with feature creep and bloat on python. With lua, I find that I barely miss any features/abilities from the vastly more complex python while the simplicity of lua means my code gets to "go places" where python can't go. With lua, you find casual implementers making fully compatible alternative implementations (e.g. NeoLua for C#, Luna for Java, fengari for JavaScript, ...) With Python, alternative implementations seemingly just can't keep up with the pace at which CPython is introducing unnecessary new features and CPython-compatbility is de-facto the only meaningful python standard there is. Jython and IronPython would make the platform so much more appealing, but they appear dead in the water. Python implementations for the browser pop up every couple of years only to see little adoption and quietly disappear again. What's more: Once you've settled on Lua as an embedding language, developers of Lua logic are free to use not just Lua, but they can pick from a host of cool transpile-to-Lua languages [1]. [1] https://github.com/hengestone/lua-languages https://github.com/hengestone/lua-languages
- tonyjstark 4y ago
  Out of personal interest, can you elaborate why Haxe turned out to be a bad idea?
  - gyulai 4y ago
    Haxe is great for when you want to write an entire application in Haxe, then transpile to multiple targets, and then care about the target platform only to the extent that you want your application to just work. The various haxe game engines are a good example of this kind of use case, where they transpile your haxe code to C++ or JavaScript and then your transpiled code combines with JavaScript code that the game engine provides or with C++ code that the game engine provides and the result is that everything "just works", both natively and in the browser. I also have high hopes for this approach in relation to GUI programming (HaxeUI, FeathersUI, etc. are very interesting). But my usecase was different: I wanted to make an API for my business logic that would transpile to Python, JavaScript and Java, and give a developer on each target platform a native look and feel, as if they were interacting with a native Python API or Java API, etc. Basically, when you do that, you'll discover that Haxe is too much of a leaky abstraction. For example when your API requires passing an iterator over Strings or returns an iterator over Strings, you'll discover that this doesn't automagically turn into java.util.Iterator<String> when you transpile to Java. Rather Haxe has its own implementation (haxe.Iterator) that transpiles to some weird Java object that a Java developer will have a difficult time interacting with. ...this is true not just for iterators but for a lot of very basic things like collections, exceptions, etc. Haxe does expose target-specific things on the Haxe-side, so you can write Haxe code that will accept java.util.Iterator or return java.util.Iterator, but, obviously, java.util.Iterator will not be available when you try to transpile to something other than Java. So whenever you want to just use an iterator, your code is going to be full of "if this platform then behave like x, if that platform then behave like y, ..." Outside of development around the main Haxe-based game engines, you'll also find that the community is just too thin to properly maintain libraries. For example, several libraries that implement very basic things haven't been touched in years and I discovered that the HashMap implementation in the Haxe standard library is just broken and no one seems to care or notice. It just doesn't handle collisions [1]. ...the only way I can explain that to myself is by assuming that there just aren't enough people using HashMaps on Haxe directly, because the game engines or target platforms provide something else that displaces that functionality or that games are just the kinds of applications where the errors that result from hash collisions aren't noticeable. The advice I got from a seasoned Haxe veteran regarding libraries was to not use haxelib and dependencies at all but instead copy & paste the library code I really needed, fighting hard to keep that to a minimum, and maintain it myself. It's a pity, because the Haxe language is great, and the ideas behind the architecture are great, but the current implementation IMO just hasn't yet made enough progress on the journey it embarked upon for Haxe to be an option yet for major investments in any non-game software development. [1] https://github.com/HaxeFoundation/haxe/blob/development/std/haxe/ds/HashMap.hx https://github.com/HaxeFoundation/haxe/blob/development/std/...
LAC-Tech 4y ago
I’m currently working on a macOS app that’s built with Racket and allows the user to write small scripts to process and filter some data. While Racket is definitely my preferred language and I could easily use it for these scripts, my target audience for this app would probably appreciate a more familiar language. I'd love to script something in racket, over lua. Is basic racket scripting even more challenging? I guess some programmers are allergic to s-expressions. But if you gave them a DSL, you could get something wonderfully expressive. Dunno. Hard for me to imagine someone grokking Lua metatables but being terrified of parens.
- Bogdanp 4y ago
  I don’t expect that these scripts will be complex enough to warrant knowing about metatables. They will mostly be about filtering data and maybe doing some math, in which case the infix notation will come in handy. That said, the app will let folks use Racket if they want to. I just don’t want to scare them off with the parens, which many people are unfortunately allergic to, as you say.
lastdong 4y ago
Love the language and how much has grown, but could never get past the 1-based indexing of table arrays.
- hypertele-Xii 4y ago
  I like it, feels more natural and intuitive to me somehow. The presence of zero should be special; it doesn't quite feel like "just another number".
  - vaylian 4y ago
    ... until you get into modulo arithmetic and then things come crashing down.
- samatman 4y ago
  Honestly, I've relaxed about that part quite a bit. Array tables are usually iterated with `ipairs`, appended with `insert`, popped with `remove` and so on. The difference between putting new stuff at `tab[#tab]` (the usual) and `tab[#tab + 1]` (the Lua style) just doesn't come up much. What is a genuine mistake, which I'll never get over, is the one-based semi-open interval string indices. Representing the spot before the first character as `1,0` is just awful, and it has real consequences for interval arithmetic, which is frequent with strings. The bugs are usually shallow, but I get really creative with cursing when I see something moved by two bytes, because I got the sign wrong on some fencepost arithmetic. pretty simple: is it (a - b + 1), (b - a + 1), (a - b - 1), or (b - a - 1)? There should only be two options. That said, it's pretty fantastic to use a language with a flaw, rather than a flawed language. I would definitely change how strings are treated, if I could, and yeah, probably zero-index tables as well, but that's about it. The lack of multiple return values in Python, requiring changes to every call site if you decide a tuple is better than a scalar, is dramatically worse than this, and I don't see people complaining much.
- CapsAdmin 4y ago
  Having used Lua and other zero indexed languages for a while, it's not that different from switching between a mac keyboard and windows keyboard. It can be annoying in the beginning, but your brain figures it out eventually.

101 points by Bogdanp 4y ago

Implementing Lua is a great way to test out your language-generating program, since Lua is an extremely simple yet popular language. CLISP or Scheme is also a great test language...though Racket already has that covered. It would be interesting to see someone implement a language like Python, C (interpreted or compiled to ASM), or Java in Racket. But it would also be an insane amount of work, probably to the point where you're almost just re-implementing the language, and I also wonder if Racket would get really slow or crash due to all of the complexity.

jmclnx 4y ago
And NetBSD has a hook to the kernel via lua https://man.netbsd.org/lua.4 https://man.netbsd.org/lua.4
- TedDoesntTalk 4y ago
  This is both insane and cool.
- canadianfella 4y ago
spdegabrielle 4y ago
Python and Java have been implemented in Racket. I believe implementing a subset of Python was also an assignment for some course. There is `#lang c` for writing C programs in DrRacket but it uses the installed C compiler, rather than re-implementing C in Racket. https://docs.racket-lang.org/c/ https://docs.racket-lang.org/c/

PenguinCoder 4y ago

Lua is a great language, simple enough to start with and do something with. Lightweight and fast. I love using Lua even though I hate having to reinvent every library worth of functions I constantly want to use elsewhere. Lua rocks is okay but I don't really like using it. Lua has a Simple syntax, easy to grasp but hard to master and achieve complexity with.

gyulai 4y ago
I suppose the more lua-esque thing to do is to not use lua in isolation and not rely on lua rocks, but instead embed it in some host language, and then rely on the host language to do the heavylifting where libraries and ecosystem are concerned. For example, if you're scripting and need to deal with yaml files, then instead of using a yaml parser from lua rocks, you might embed lua in python through lupa and then expose PyYAML through lupa to your lua code. This sounds limiting, but it's actually liberating. Depending on what it is you're actually doing, you can just pick the host language and the libraries you want to use in a way that best integrates with the things you need to integrate with.
- maccard 4y ago
  > then instead of using a yaml parser from lua rocks, you might embed lua in python through lupa and then expose PyYAML through lupa to your lua code. Well this might take the cake for the most bizarre suggestion I read online this weekend. If someone on my team genuinely suggested embedding an interpreted language inside another interpreted language that we have embedded in a static language, just to load config files, I would genuinely think they're totally out of touch.
  - gyulai 4y ago
    "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize." [1] Embedding python in something else was not part of my suggestion, rather I suggested using python in cases like scripting, where python would already be a good choice of an ecosystem. Also YAML-parsing was merely an example, and I wasn't necessarily envisioning that parsing a config file was the only actual purpose it would serve. The fact is that no piece of code ever exists in a vacuum. It's always part of some application ecosystem, e.g. Windows GUI programming in C#, apache spark based ETL development in Java, scientific computation in Python, etc. ...most applications have an ecosystem (language+libraries) that's a clear "winner" in terms of adoption and richness of functionality for the given application. My suggestion is merely this: Just go with the flow, pick the winning ecosystem, then embed lua and write your own stuff in lua while exposing whatever bits of ecosystem you need to integrate with to lua through some minimal logic that exists on the host language side. If you context-switch at any point in the future, that gives you a good chance of being able to reuse your lua code. For example say you've developed some highly specialized piece of math for a scientific data crunching project in Python. Now you want to use that math in a GUI. Just embed lua in a host environment that's good for GUI development. ...chances are you'll be able to reuse that Lua code. If you had written the math library in Python to begin with, you're now in the difficult situation of being forced to use Python for GUI development, embedding Python in something that's good for GUI development, rewriting your code, all of which are pretty bad options and Lua might be a lesser evil. [1] https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

andrewmcwatters 4y ago

Bogdan, not sure if this interests you since you've already commented on your approach in the article, but at Planimeter we use some utility scripts based on some comments at StackOverflow by Jonathan Leffler that help autogen LuaJIT FFI bindings. We started the luajit-ffi-bindings[1] tag at GitHub. If you're ever interested in their practical usage, Google me and let me know. [1]: https://github.com/topics/luajit-ffi-bindings https://github.com/topics/luajit-ffi-bindings

andrewmcwatters 4y ago
https://github.com/Planimeter/lffiutils https://github.com/Planimeter/lffiutils

gus_massa 4y ago

> a couple things are still missing lexer support (long brackets, scientific notation for numbers) How much of the standard Lua test suit can your implementation pass? Do you have some benchmarks to compare the speed? What is the problem with scientific notation? Racket can parse floating point numbers, including some weird cases [1], but I guess Lua has a slightly different set of weird cases. [1] From https://news.ycombinator.com/item?id=15628989 https://news.ycombinator.com/item?id=15628989 > Eli Barzley pointed out that Racket[BC] reads #e#x+e#s+e-e#l-e as a number.

Bogdanp 4y ago
> How much of the standard Lua test suit can your implementation pass? I haven't tried it yet, but I don't believe it would get very far since I haven't yet exposed ways to load Lua code from Lua modules (`dofile`, `load`, `require`, etc.). I've been building up my own test suite[1] while working through the reference manual[2]. I had never really used Lua before this, so it's been pretty interesting learning the language while implementing it. > Do you have some benchmarks to compare the speed? I've been using programs from the benchmarks game[3] and comparing them against regular Lua on my machine. On these programs, the overhead is usually somewhere around 2-3x. I believe that's mostly because these programs tend to be very mutation heavy. It's also possible that the way I'm compiling things down to Racket is defeating optimizations, but I haven't yet dug in. If you're curious, you can get it to print the code it generates for any given module by setting the `RACKET_LUA_DEBUG` env var to `x` before running some code. Eg: $ echo -e '#lang lua\nprint(1)' > test.lua $ env RACKET_LUA_DEBUG=x racket test.lua <<test.lua>> '((#%provide #%chunk) (#%define _ENV (#%global)) (#%load-stdlib! _ENV) (#%define (#%lua-module . #%rest) (#%begin (#%begin (print 1)) (#%values))) (#%define #%chunk (#%adjust (#%lua-module)))) 1 > What is the problem with scientific notation? Racket can parse floating point numbers, including some weird cases [1], but I guess Lua has a slightly different set of weird cases. Yup. I just haven't gotten around to it. My goal this week has been to get it to a usable spot for embedding in my app and then iterate from there. [1]: https://github.com/Bogdanp/racket-lua/tree/master/lua-test/lua/examples https://github.com/Bogdanp/racket-lua/tree/master/lua-test/l... [2]: https://www.lua.org/manual/5.4/manual.html https://www.lua.org/manual/5.4/manual.html [3]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ https://benchmarksgame-team.pages.debian.net/benchmarksgame/

felipelalli 4y ago

Good job!

gyulai 4y ago

I feel the need to ramble slightly OT on how great Lua is: I was looking for an architecture/tech stack recently that would allow me to develop a cross-platform desktop GUI. I went on a several-weeks-long fact finding mission (the longest of its kind I've ever done in my 10 years as a professional software developer). The option that won was to write all business logic (a few thousand lines of code) in Lua, then write the GUI in each platform's native language+ui-library combination and re-use the same business logic by embedding Lua. Another option that made the shortlist was using Haxe instead of Lua, but after several weeks of active Haxe development, it became clear that that was a bad idea, and with Lua, the developer experience is now so much better. I definitely plan on continuing to use Lua as my main programming language. This comes after 20 years of having python as my main programming language because I'm displeased with feature creep and bloat on python. With lua, I find that I barely miss any features/abilities from the vastly more complex python while the simplicity of lua means my code gets to "go places" where python can't go. With lua, you find casual implementers making fully compatible alternative implementations (e.g. NeoLua for C#, Luna for Java, fengari for JavaScript, ...) With Python, alternative implementations seemingly just can't keep up with the pace at which CPython is introducing unnecessary new features and CPython-compatbility is de-facto the only meaningful python standard there is. Jython and IronPython would make the platform so much more appealing, but they appear dead in the water. Python implementations for the browser pop up every couple of years only to see little adoption and quietly disappear again. What's more: Once you've settled on Lua as an embedding language, developers of Lua logic are free to use not just Lua, but they can pick from a host of cool transpile-to-Lua languages [1]. [1] https://github.com/hengestone/lua-languages https://github.com/hengestone/lua-languages

tonyjstark 4y ago
Out of personal interest, can you elaborate why Haxe turned out to be a bad idea?
- gyulai 4y ago
  Haxe is great for when you want to write an entire application in Haxe, then transpile to multiple targets, and then care about the target platform only to the extent that you want your application to just work. The various haxe game engines are a good example of this kind of use case, where they transpile your haxe code to C++ or JavaScript and then your transpiled code combines with JavaScript code that the game engine provides or with C++ code that the game engine provides and the result is that everything "just works", both natively and in the browser. I also have high hopes for this approach in relation to GUI programming (HaxeUI, FeathersUI, etc. are very interesting). But my usecase was different: I wanted to make an API for my business logic that would transpile to Python, JavaScript and Java, and give a developer on each target platform a native look and feel, as if they were interacting with a native Python API or Java API, etc. Basically, when you do that, you'll discover that Haxe is too much of a leaky abstraction. For example when your API requires passing an iterator over Strings or returns an iterator over Strings, you'll discover that this doesn't automagically turn into java.util.Iterator<String> when you transpile to Java. Rather Haxe has its own implementation (haxe.Iterator) that transpiles to some weird Java object that a Java developer will have a difficult time interacting with. ...this is true not just for iterators but for a lot of very basic things like collections, exceptions, etc. Haxe does expose target-specific things on the Haxe-side, so you can write Haxe code that will accept java.util.Iterator or return java.util.Iterator, but, obviously, java.util.Iterator will not be available when you try to transpile to something other than Java. So whenever you want to just use an iterator, your code is going to be full of "if this platform then behave like x, if that platform then behave like y, ..." Outside of development around the main Haxe-based game engines, you'll also find that the community is just too thin to properly maintain libraries. For example, several libraries that implement very basic things haven't been touched in years and I discovered that the HashMap implementation in the Haxe standard library is just broken and no one seems to care or notice. It just doesn't handle collisions [1]. ...the only way I can explain that to myself is by assuming that there just aren't enough people using HashMaps on Haxe directly, because the game engines or target platforms provide something else that displaces that functionality or that games are just the kinds of applications where the errors that result from hash collisions aren't noticeable. The advice I got from a seasoned Haxe veteran regarding libraries was to not use haxelib and dependencies at all but instead copy & paste the library code I really needed, fighting hard to keep that to a minimum, and maintain it myself. It's a pity, because the Haxe language is great, and the ideas behind the architecture are great, but the current implementation IMO just hasn't yet made enough progress on the journey it embarked upon for Haxe to be an option yet for major investments in any non-game software development. [1] https://github.com/HaxeFoundation/haxe/blob/development/std/haxe/ds/HashMap.hx https://github.com/HaxeFoundation/haxe/blob/development/std/...

LAC-Tech 4y ago

I’m currently working on a macOS app that’s built with Racket and allows the user to write small scripts to process and filter some data. While Racket is definitely my preferred language and I could easily use it for these scripts, my target audience for this app would probably appreciate a more familiar language. I'd love to script something in racket, over lua. Is basic racket scripting even more challenging? I guess some programmers are allergic to s-expressions. But if you gave them a DSL, you could get something wonderfully expressive. Dunno. Hard for me to imagine someone grokking Lua metatables but being terrified of parens.

Bogdanp 4y ago
I don’t expect that these scripts will be complex enough to warrant knowing about metatables. They will mostly be about filtering data and maybe doing some math, in which case the infix notation will come in handy. That said, the app will let folks use Racket if they want to. I just don’t want to scare them off with the parens, which many people are unfortunately allergic to, as you say.

lastdong 4y ago

Love the language and how much has grown, but could never get past the 1-based indexing of table arrays.

hypertele-Xii 4y ago
I like it, feels more natural and intuitive to me somehow. The presence of zero should be special; it doesn't quite feel like "just another number".
- vaylian 4y ago
  ... until you get into modulo arithmetic and then things come crashing down.
samatman 4y ago
Honestly, I've relaxed about that part quite a bit. Array tables are usually iterated with `ipairs`, appended with `insert`, popped with `remove` and so on. The difference between putting new stuff at `tab[#tab]` (the usual) and `tab[#tab + 1]` (the Lua style) just doesn't come up much. What is a genuine mistake, which I'll never get over, is the one-based semi-open interval string indices. Representing the spot before the first character as `1,0` is just awful, and it has real consequences for interval arithmetic, which is frequent with strings. The bugs are usually shallow, but I get really creative with cursing when I see something moved by two bytes, because I got the sign wrong on some fencepost arithmetic. pretty simple: is it (a - b + 1), (b - a + 1), (a - b - 1), or (b - a - 1)? There should only be two options. That said, it's pretty fantastic to use a language with a flaw, rather than a flawed language. I would definitely change how strings are treated, if I could, and yeah, probably zero-index tables as well, but that's about it. The lack of multiple return values in Python, requiring changes to every call site if you decide a tuple is better than a scalar, is dramatically worse than this, and I don't see people complaining much.
CapsAdmin 4y ago
Having used Lua and other zero indexed languages for a while, it's not that different from switching between a mac keyboard and windows keyboard. It can be annoying in the beginning, but your brain figures it out eventually.