5 ms·

Lua will never be more popular without a proper standard library. Leaving everything up to the user so that you have to manually implement (or hunt the web for

by ebg13 6y ago

Lua will never be more popular without a proper standard library. Leaving everything up to the user so that you have to manually implement (or hunt the web for) even the most basic features is mega annoying. How many millions of people need to rewrite string.startswith? The whole "sequence iteration stops at the first internal hole and therefore the # operator doesn't do what you think it should" gotcha is extremely user hostile. Metatables are cool and all, but holy crap are they confusing for Lua newbies. Having an integrated class system would go a long way.

fit2rule 6y ago
1. Luarocks. 2. I regularly carry these little enumerables around with me and use it so frequently I found it quaint to be reminded of the 'hole problem': --- get all packed entries, until gap -- func on the provided list -- @param list table to be inspected -- @param func do func what you func want table.each = function(list, func) for i,v in ipairs(list) do func(v, i) end end --- get all entries, packed or not, until completion -- func on the provided list, completely -- @param list table to be inspected -- @param func do func what you func want table.all = function(list, func) if (list ~= nil) then for i,v in pairs(list) do func(v, i) end end end Disclaimer: I love Lua and would us it for everything if I could.
- ebg13 6y ago
  Do you also carry a table deepcopy with you? What about string.trim? And LuaRocks is a trash fire that doesn't integrate well with Lua's primary role as an embedded plugin engine and leaves you to waste your time in endless discovery of a slew of unmaintained packages that all do the same thing in different ways and with different bugs. Want to collaborate? I hope everyone is familiar with "classy" and not "oops" or "objectlua" or "Luaoop" or "lobject" or "classyng" or "klesi" or "halo" or "lua-c3class" or "pool" or "middleclass" or "Sunclass" or any other module that implements one of the half dozen official recommendations for faking classes with metatables or closures. It also becomes a huge "left-pad" risk.
  - fit2rule 6y ago
    Table deepcopy: table.unpack() does pretty much everything I've ever needed it to do, but for those tricker tables, there's always https://gist.github.com/tylerneylon/81333721109155b2d244 https://gist.github.com/tylerneylon/81333721109155b2d244 - and I freely admit that yes, the link to that gist is in my "Lua dev notes" bookmarks file, which I refer to often. Hmmm ... string.trim: umm, not really something I find I need, a lot of times.. but as usual, Lua-users provides some incite into why, exactly, its not always as simple as one might think. (http://lua-users.org/wiki/StringTrim http://lua-users.org/wiki/StringTrim) As for your brilliant discourse on Luarocks, ok. Not gonna get any resistance from me on that. I know the pain you describe. But I have had success with using it to copy environments on other machines 99% of the time .. which is not what I could say about the hell that python has put me through, at times. But I guess that's par for the course.
    - ebg13 6y ago
      > as usual, Lua-users provides some incite into... (insight) It makes me sad that Lua's refusal to standardize good ways to do things led to the language's primary resource being a community message board filled with back-and-forth postcard essays saying "I tried this and it didn't work. Then I tried this and it didn't work." followed by someone else responding "Have you tried this?" and then yet another person saying "No, that doesn't work either." It's absolutely awful, and I hate myself every time I land on the Lua-users site. I linked to it in another comment, but http://lua-users.org/wiki/SplitJoin http://lua-users.org/wiki/SplitJoin is a perfect example. The document starts with "split and join are two common string operators". Note the word "common"! Then it promptly throws up its hands at declaring a reasonable interface and proceeds to plow ahead for literally pages of failed attempts that don't work right! Even your link to StringTrim, which at least doesn't dick around with a ream of implementations that don't even work, provides _15_ different obscure as hell implementations, many of which only differ meaningfully in performance on really stupid cases, and the clearly superior one is in C, not Lua, so you can't even use it! But Lua itself could have used it and saved everyone the headache! People shouldn't have to deal with this mess for "common operations".
      - 6y ago
pansa2 6y ago
> Lua will never be more popular without a proper standard library. How would you add a large standard library without compromising Lua’s main purpose - to be a lightweight, embeddable language?
- ebg13 6y ago
  It would still be lightweight and embeddable with common sense pure Lua functionality like classes and major utility methods like string.startswith/string.endswith/string.trim/string.split/table.deepcopy. You don't have to integrate a multiprocessing web server for different operating systems. Instead you're left with bullshit community essays like http://lua-users.org/wiki/SplitJoin http://lua-users.org/wiki/SplitJoin which shows pages and pages of different user attempts for one extremely common function, many of which explicitly do not work! Lua has its strengths, but faffing about refusing to just standardize the right way to do things is super user-hostile.
  - pull_my_finger 6y ago
    Lua, by design, favors "mechanisms not policy"[1]. It's not a failing it meant to empower users. There are plenty of mature utility libraries that serve for batteries if you like that. [1] - http://lua-users.org/wiki/MechanismNotPolicy http://lua-users.org/wiki/MechanismNotPolicy
    - ebg13 6y ago
      > It's not a failing it meant to empower users. Freedom to implement bespoke solutions is great if what you want to spend your time on is implementing bespoke solutions. Freedom from needing to implement bespoke solutions is better for everyone. Even non-programmers can understand what common simple operations are for and when they might be useful. Saying that one needs to know how to implement or find them as well, especially when a bunch of extremely learned participants in lua-users can repeatedly fail to implement working versions, is literally the opposite of empowering.
      - 6y ago
aasasd 6y ago
Ah, yes, the table length/ iteration thing probably deserves the second place or a tie in the annoyances. The library thing is eh: just grab Penlight if you aren't running Lua on a microchip.
- deleted 6y ago
  [deleted]
dwheeler 6y ago
Agreed. One of the reasons that Python grew popular so fast was its "batteries included" approach. When a developer needs to do some common thing, it's really helpful to have one obvious way to do it that is highly reliable and well integrated with the rest of the system.
- hhas01 6y ago
  “it's really helpful to have one obvious way” Counterpoint: Python format strings. (I think there’s four or five different built-in ways to do those now.) Python’s “batteries included” may have helped it to win vital audience early on, but it’s also locked in a ton of deadweight that’s seriously slowed down its own evolution since, while bloating its feature complexity to such a level I could not recommend Python as a good language for beginners now. Which suggests there’s a more general meta-problem waiting to be solved here: how to [automatically] mass-migrate code written against interface A when a superior successor B comes along. I have many gripes about Apple’s #SwiftLang, but seriously appreciate that this is one requirement they’ve given some thought to. Having seen the decade-long logistical horror of Python’s relatively minor 2-to-3 upgrade, Xcode’s ability to auto-update projects written for one Swift version to another has let them evolve the language with minimal pain. And while I’m not a fan of Lisp itself (a decent first attempt that should’ve been vastly bettered by now), I think its metaprogramming model an obvious foundation for such an automated migration system. Thus, rather than bake in all the libraries, keep the libraries external and build in a standard mechanism for migrating codebases written for one onto another. In essence, automated refactoring by “recipes”, where these recipes are as common and easy-to-use as the libraries themselves. .. Of course, this still leaves the other (larger) problem of how to sort out current trash houses like PyPI, NPM, LuaRocks, et al, where contributors’ enthusiasm is not necessarily matched by their knowledge, competence, and ability to savagely critique their own work before inflicting it on the world (you know, the “Science” bit in “Computer Science”). Preferably without destroying that enthusiasm in the process, since there’s no point having a wonderfully polished platform without bums on seats as well—a perennial Lisp failing, it should be noted. This is not merely idle speculation on my part. Many years ago I cut my teeth on AppleScript, which makes the stdlib-starved Lua look like fat Python 2, and tried to bootstrap a library ecosystem for it more than once. Good practice. Zero success†. And now I’m trying to devise a “stealth Lisp” successor to them all (https://github.com/hhas/iris-script https://github.com/hhas/iris-script), I realise cracking the greater library problem is what will make the next generation of languages. A platform is only as robust and dependable as its weakest component, and for as long as a buggy or withdrawn left-pad function can tip the whole stack over then it’s not robust at all. But this is as much a sociological challenge as a technical one, and not one I’ve got answers to yet. -- † After which I realized it’d be far easier just to port the useful bits of AppleScript to Python instead. Which almost worked too… but that’s another story.

by ebg13 6y ago

fit2rule 6y ago

1. Luarocks. 2. I regularly carry these little enumerables around with me and use it so frequently I found it quaint to be reminded of the 'hole problem': --- get all packed entries, until gap -- func on the provided list -- @param list table to be inspected -- @param func do func what you func want table.each = function(list, func) for i,v in ipairs(list) do func(v, i) end end --- get all entries, packed or not, until completion -- func on the provided list, completely -- @param list table to be inspected -- @param func do func what you func want table.all = function(list, func) if (list ~= nil) then for i,v in pairs(list) do func(v, i) end end end Disclaimer: I love Lua and would us it for everything if I could.

ebg13 6y ago
Do you also carry a table deepcopy with you? What about string.trim? And LuaRocks is a trash fire that doesn't integrate well with Lua's primary role as an embedded plugin engine and leaves you to waste your time in endless discovery of a slew of unmaintained packages that all do the same thing in different ways and with different bugs. Want to collaborate? I hope everyone is familiar with "classy" and not "oops" or "objectlua" or "Luaoop" or "lobject" or "classyng" or "klesi" or "halo" or "lua-c3class" or "pool" or "middleclass" or "Sunclass" or any other module that implements one of the half dozen official recommendations for faking classes with metatables or closures. It also becomes a huge "left-pad" risk.
- fit2rule 6y ago
  Table deepcopy: table.unpack() does pretty much everything I've ever needed it to do, but for those tricker tables, there's always https://gist.github.com/tylerneylon/81333721109155b2d244 https://gist.github.com/tylerneylon/81333721109155b2d244 - and I freely admit that yes, the link to that gist is in my "Lua dev notes" bookmarks file, which I refer to often. Hmmm ... string.trim: umm, not really something I find I need, a lot of times.. but as usual, Lua-users provides some incite into why, exactly, its not always as simple as one might think. (http://lua-users.org/wiki/StringTrim http://lua-users.org/wiki/StringTrim) As for your brilliant discourse on Luarocks, ok. Not gonna get any resistance from me on that. I know the pain you describe. But I have had success with using it to copy environments on other machines 99% of the time .. which is not what I could say about the hell that python has put me through, at times. But I guess that's par for the course.
  - ebg13 6y ago
    > as usual, Lua-users provides some incite into... (insight) It makes me sad that Lua's refusal to standardize good ways to do things led to the language's primary resource being a community message board filled with back-and-forth postcard essays saying "I tried this and it didn't work. Then I tried this and it didn't work." followed by someone else responding "Have you tried this?" and then yet another person saying "No, that doesn't work either." It's absolutely awful, and I hate myself every time I land on the Lua-users site. I linked to it in another comment, but http://lua-users.org/wiki/SplitJoin http://lua-users.org/wiki/SplitJoin is a perfect example. The document starts with "split and join are two common string operators". Note the word "common"! Then it promptly throws up its hands at declaring a reasonable interface and proceeds to plow ahead for literally pages of failed attempts that don't work right! Even your link to StringTrim, which at least doesn't dick around with a ream of implementations that don't even work, provides _15_ different obscure as hell implementations, many of which only differ meaningfully in performance on really stupid cases, and the clearly superior one is in C, not Lua, so you can't even use it! But Lua itself could have used it and saved everyone the headache! People shouldn't have to deal with this mess for "common operations".
    - 6y ago

pansa2 6y ago

> Lua will never be more popular without a proper standard library. How would you add a large standard library without compromising Lua’s main purpose - to be a lightweight, embeddable language?

ebg13 6y ago
It would still be lightweight and embeddable with common sense pure Lua functionality like classes and major utility methods like string.startswith/string.endswith/string.trim/string.split/table.deepcopy. You don't have to integrate a multiprocessing web server for different operating systems. Instead you're left with bullshit community essays like http://lua-users.org/wiki/SplitJoin http://lua-users.org/wiki/SplitJoin which shows pages and pages of different user attempts for one extremely common function, many of which explicitly do not work! Lua has its strengths, but faffing about refusing to just standardize the right way to do things is super user-hostile.
- pull_my_finger 6y ago
  Lua, by design, favors "mechanisms not policy"[1]. It's not a failing it meant to empower users. There are plenty of mature utility libraries that serve for batteries if you like that. [1] - http://lua-users.org/wiki/MechanismNotPolicy http://lua-users.org/wiki/MechanismNotPolicy
  - ebg13 6y ago
    > It's not a failing it meant to empower users. Freedom to implement bespoke solutions is great if what you want to spend your time on is implementing bespoke solutions. Freedom from needing to implement bespoke solutions is better for everyone. Even non-programmers can understand what common simple operations are for and when they might be useful. Saying that one needs to know how to implement or find them as well, especially when a bunch of extremely learned participants in lua-users can repeatedly fail to implement working versions, is literally the opposite of empowering.
    - 6y ago

aasasd 6y ago

Ah, yes, the table length/ iteration thing probably deserves the second place or a tie in the annoyances. The library thing is eh: just grab Penlight if you aren't running Lua on a microchip.

deleted 6y ago
[deleted]

dwheeler 6y ago

Agreed. One of the reasons that Python grew popular so fast was its "batteries included" approach. When a developer needs to do some common thing, it's really helpful to have one obvious way to do it that is highly reliable and well integrated with the rest of the system.

hhas01 6y ago
“it's really helpful to have one obvious way” Counterpoint: Python format strings. (I think there’s four or five different built-in ways to do those now.) Python’s “batteries included” may have helped it to win vital audience early on, but it’s also locked in a ton of deadweight that’s seriously slowed down its own evolution since, while bloating its feature complexity to such a level I could not recommend Python as a good language for beginners now. Which suggests there’s a more general meta-problem waiting to be solved here: how to [automatically] mass-migrate code written against interface A when a superior successor B comes along. I have many gripes about Apple’s #SwiftLang, but seriously appreciate that this is one requirement they’ve given some thought to. Having seen the decade-long logistical horror of Python’s relatively minor 2-to-3 upgrade, Xcode’s ability to auto-update projects written for one Swift version to another has let them evolve the language with minimal pain. And while I’m not a fan of Lisp itself (a decent first attempt that should’ve been vastly bettered by now), I think its metaprogramming model an obvious foundation for such an automated migration system. Thus, rather than bake in all the libraries, keep the libraries external and build in a standard mechanism for migrating codebases written for one onto another. In essence, automated refactoring by “recipes”, where these recipes are as common and easy-to-use as the libraries themselves. .. Of course, this still leaves the other (larger) problem of how to sort out current trash houses like PyPI, NPM, LuaRocks, et al, where contributors’ enthusiasm is not necessarily matched by their knowledge, competence, and ability to savagely critique their own work before inflicting it on the world (you know, the “Science” bit in “Computer Science”). Preferably without destroying that enthusiasm in the process, since there’s no point having a wonderfully polished platform without bums on seats as well—a perennial Lisp failing, it should be noted. This is not merely idle speculation on my part. Many years ago I cut my teeth on AppleScript, which makes the stdlib-starved Lua look like fat Python 2, and tried to bootstrap a library ecosystem for it more than once. Good practice. Zero success†. And now I’m trying to devise a “stealth Lisp” successor to them all (https://github.com/hhas/iris-script https://github.com/hhas/iris-script), I realise cracking the greater library problem is what will make the next generation of languages. A platform is only as robust and dependable as its weakest component, and for as long as a buggy or withdrawn left-pad function can tip the whole stack over then it’s not robust at all. But this is as much a sociological challenge as a technical one, and not one I’ve got answers to yet. -- † After which I realized it’d be far easier just to port the useful bits of AppleScript to Python instead. Which almost worked too… but that’s another story.