-Andrew Starks Tightrope Media Systems (612) 840-2939
"As we get older, and stop making sense"-David Byrne Following the discussions on Lua modules/Packages, binary distributions and Lua popularity (or lack thereof) as a language, and believing these things are all related, I did some research. Here are some preliminary notes and findings:
� 1. As a general comment, it is hard to navigate the very fragmented Lua ecosystem. The Community WiKi ought to be the starting point, but you'd be hard pressed to find important parts of the ecosystem starting there or to navigate what is salient today rather than being of historical interest only.
� 2. wxLua: This is a great cross-platform GUI LUA IDE, written in Lua, although that is not how it is sold! It provides a binary distribution of both Lua 5.1 and Lua 5.2, but for Windows only (even though the source code is cross-platform). There is an outdated binary for OSX, but none at all for Linux. It does not address package management.
� 3. LuaRocks: A non-GUI command-line system. Binary distribution for Windows (but stuck at Lua 5.1) and instructions for Linux, hints this should work on OSX, but no specific information. A "rockspec" was kindly provided for me for my "bitfield" C extension, but so far I have failed to get this to build on Windows. I just get a very unhelpful error message on the command console.
� 4. LuaDist: Again strictly command-line. Binary distributions for the three major platforms, but these do not include a distribution of Lua itself, only the system for handling modules/packages.
� 5. Lua.App (Luiz Henrique de Figueiredo): Graphical (very basic) runtime for OSX with a binary distribution of Lua 5.2 and a selection of binary modules. The C modules could be easily added to, but only if you have them in appropriate binary form (are Linux .so files the same as OSX ones?) as it does not address building them from C.
� The ideal: wxLua's IDE extended to support package management (LuaRocks and/or LuaDist) from the GUI. It should be able to compile C source modules at least for the native platform, but preferably also cross-compile for the other platforms. The GUI should also support packaging of applications and here 5 shows the way - package the runtime, the binary C modules and the Lua scripts as a folder with a bootstrap in the root directory. This will work natively in OSX, pretty well on Windows and ought to be doable on Linux (though execution permissions are a knotty problem to be solved). There need to be binary distributions for all platforms of both Lua 5.1 and Lua 5.2.
� Everything needed for a good beginner experience is there - it is just horribly fragmented and difficult to find. The problem is this: beginners discover a lovely, minimalistic but powerful language ideal for learning programming, but in order to put it to practical use they find they have to first master C (or at least building from C sources) and in order to achieve that they have to learn baroque build languages and command line interfaces. Unsurprisingly most just give up and settle for an ugly, bloated language like _javascript_, which they can use 'out of the box'.
�
A bit after 5.2 came out, I started yelling about this. Then someone pointed out that for them an "ecosystem" wasn't a thing that they cared about because Lua isn't Perl.�
That stuck with me.�
Today, I hand place a few basic modules into my own "VM/app" like tree structure that is 100% compatible with nothing. If I cannot beat the source into working in a VS2010 SLN, and then make it work compile using make, then it doesn't exist.�
We ship Lua and it's dependancies, wrapped up in a product that we then need to maintain. LuaRocks, or any other such madness would, would make little sense in this context. As much as is use Lua for scripting, my dev environment is set up to accommodate my weird, hand-rolled structure. So, even when it would make sense to use LR or LD, it doesn't and even if it could be made to work, I don't really care.�
That does not take away from the value of this work for others. I don't intend to sound negative toward the effort.�
My suggestion is that Lua is not at all "less popular." In the circles in which, in my estimation, it absolutely dominates, package managers represent the introduction of potential hair balls, installed in ways that are perhaps "wrong", and done so out side of the build scripts being used to build a larger project.�
Take away all of the developers in the Luaverse for which that is true, and Lua truly is a niche language.�
Maybe all these words wind up coming down to the suggestion that you're not solving a problem. You may be extending the core base of users.�
I hope that people who make useful libraries continue to remember that a totmopt mOtg
|
