 |
lua-l archive |
|
|
||
|
On Feb 25, 2016 3:37 AM, "Geoff Leyland" <geoff_leyland@fastmail.fm> wrote:
>
>
> > On 25/02/2016, at 9:18 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> >
> > I have the perception that >90% of the rocks available on the primary
> > repository provide modules and <10% provide applications, and the
> > suspicion that 10% is a very generous estimate.
> >
> > Yet I find it hard to believe that 90% of the time of a typical Lua
> > programmer is spent in developing tools and 10% in developing
> > applications.
>
> Aren't applications just libraries that you can't automate?
>
Lately I've been writing Python, and it seems to blur the line between application and library. Many modules are designed to be used in an application, but can also be invoked directly as an application themselves. This is one of my favorite aspects of Python, and feels quite "unixy". If you want to automate or embed an app or give it a different UI, you just load it as a module and call its methods. (And the standalone functionality gives you an example of how to use it!)
As far as Lua applications, I think Lua is a fantastic language, but the stock interpreter provides much too little in terms of libraries (especially to interface with the host OS) for standalone apps. You end up importing a lot of third party modules and reinventing a lot of wheels.
This is by no means a criticism. The stock interpreter isn't designed to be host to large applications, just as the 3-volt lights in a "my first electrical circuits" kit aren't designed to light your house. It's just a simple example of how to build what you want. (I think this is why the manual calls it a sample.)
To write full-blown standalone applications in Lua, I think the place to start would be to write an interpreter designed for that purpose, that offers more built-in modules to interface with the host OS. Meanwhile Lua itself remains a small, simple language, suitable for embedding even where there is no OS. That's one of my favorite aspects of Lua - mechanism, not policy. You're free to build something as extensive as Python's stock interpreter, and enforce as strict policies as you like, if that's what you want to do.