Two types of Lua programmer, or two types of Lua code?

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Two types of Lua programmer, or two types of Lua code?

Dirk Laurie-2
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.

I can think of several possible explanations.

1. Many of those modules are really stripped-down applications.
Just wrap them with I/O or a GUI, and presto!
2. Most of what we really do is confidential and can't be shared.
3. We are prepared to polish and document our tools but the
effort is just too much for the application.
4. We just don't think anybody else would be interested in the
application.
5. The whole way that LuaRocks is structured encourages the
module approach to the point that nothing else really fits.

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Daurnimator
On 25 February 2016 at 19:18, Dirk Laurie <[hidden email]> 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.
>
> I can think of several possible explanations.
>
> 1. Many of those modules are really stripped-down applications.
> Just wrap them with I/O or a GUI, and presto!

This is a good thing!
All good applications are just wrappers around a library.

> 2. Most of what we really do is confidential and can't be shared.

I'm sort of up this alley with my $DAYJOB.
I try to release all the lua libraries I can that aren't "secret sauce".

> 3. We are prepared to polish and document our tools but the
> effort is just too much for the application.

The lack of documentation for released libraries suggests this isn't a
common path of reasoning.

> 4. We just don't think anybody else would be interested in the
> application.

Sort of; see below.

> 5. The whole way that LuaRocks is structured encourages the
> module approach to the point that nothing else really fits.

Not at all IMO.
See the various tools that are installed via luarocks; ones I use
daily: busted, luacheck.

===============

I think there is another category: people write single use scripts and utilities
e.g. converting files, data processing, personal automation.

For these applications, you often need to build a library to operate
with the device or create a binding to a library, which deserves to be
released,
but the application is dead code the minute it is written.

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Geoff Leyland
In reply to this post by Dirk Laurie-2

> On 25/02/2016, at 9:18 PM, Dirk Laurie <[hidden email]> 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?

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Jonathan Goble
In reply to this post by Daurnimator
On Thu, Feb 25, 2016 at 3:31 AM, Daurnimator <[hidden email]> wrote:
> I think there is another category: people write single use scripts and utilities
> e.g. converting files, data processing, personal automation.

This is me. I initially starting learning Lua (my first true
programming language, if you don't count the BASIC I wrote as a kid on
my RadioShack Tandy PC-4) as a means of automating some tedious tasks
for a forum-based roleplaying game. You're welcome to look at the
butt-ugly script I wrote [1][2], though I warn you that it reflects my
lack of programming skills at the time, and as such you are welcome to
laugh at and make fun of it. :-) I would never write something like
that today. I mostly use Python for that purpose (personal automation)
today, but there are still occasions where I find Lua to be easier
(such as code that makes heavy use of associative arrays, for which
Lua has cleaner syntax versus Python dicts, and anything that can
benefit from tail call elimination, which Python doesn't do).

As for application vs. module on LuaRocks, the one thing I have on
LuaRocks (matchext) is by its nature a module, though one that could
probably be easily integrated into an application. That brings me to
another point: well-written modules, especially pure C modules, can be
easily integrated with an application to extend its capabilities
beyond pure Lua. So having a large number of modules is useful for
application writers.

[1] Main script:
http://limmierpg.wikia.com/wiki/User:Master_Jonathan/generator.lua
[2] Data file: http://limmierpg.wikia.com/wiki/User:Master_Jonathan/data.lua

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Viacheslav Usov
In reply to this post by Dirk Laurie-2
On Thu, Feb 25, 2016 at 9:18 AM, Dirk Laurie <[hidden email]> 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.

Given that Lua is officially an "extension language", the scarcity of all-Lua applications should hardly be surprising.

Cheers,
V.

[1] "Lua is an extension programming language [...], Lua has no notion of a "main" program: it only works embedded in a host client, called the embedding program or simply the host."  - http://www.lua.org/manual/5.3/manual.html
Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Jerome Vuarand
In reply to this post by Dirk Laurie-2
2016-02-25 8:18 GMT+00:00 Dirk Laurie <[hidden email]>:
> 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.

IMHO that's because most Lua code written is unpaid work. A good
application is likely modularized, so when you want to publish it
you'd release one module at a time. You follow the dependency graph,
releasing things with no dependencies first, self-contained libraries,
and growing from there, with the app itself last. But as unpaid work
that solves no use case for you, you're likely to give up in the
middle, with a bunch of libraries published, and the app lingering in
the output queue forever.

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Javier Guerra Giraldez
On 25 February 2016 at 11:27, Jerome Vuarand <[hidden email]> wrote:
> You follow the dependency graph,
> releasing things with no dependencies first, self-contained libraries,
> and growing from there, with the app itself last. But as unpaid work
> that solves no use case for you, you're likely to give up in the
> middle, with a bunch of libraries published, and the app lingering in
> the output queue forever.


happened to me several times!  no regrets, learned a lot from each

(but of course, that doesn't affect the observed LuaRocks ratio, since
none of my libraries is there)

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Pierre Chapuis
In reply to this post by Dirk Laurie-2
> 2. Most of what we really do is confidential and can't be shared.

This is certainly part of it. At least in my case it is.

> 4. We just don't think anybody else would be interested in the
> application.
> 5. The whole way that LuaRocks is structured encourages the
> module approach to the point that nothing else really fits.

LuaRocks is a tool used primarily by Lua developers. If I
write a re-usable module, the end user is probably going to
be a Lua developer and it makes sense to publish it through
LuaRocks. If I write an application, the end user may not be
a Lua developer and it may make more sense to distribute it
in another way.

--
Pierre Chapuis


Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Jay Carlson
In reply to this post by Daurnimator

> On 2016-02-25, at 3:31 AM, Daurnimator <[hidden email]> wrote:
>
> I think there is another category: people write single use scripts and utilities
> e.g. converting files, data processing, personal automation.

In the mid 1990s, I observed that there were more available Scheme implementations than available Scheme applications.

The great majority of all software is for internal use.
Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Stefano
In reply to this post by Viacheslav Usov


On 25 Feb 2016 11:15, "Viacheslav Usov" <[hidden email]> wrote:
>
> On Thu, Feb 25, 2016 at 9:18 AM, Dirk Laurie <[hidden email]> 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.
>
> Given that Lua is officially an "extension language", the scarcity of all-Lua applications should hardly be surprising.
>
> Cheers,
> V.
>
> [1] "Lua is an extension programming language [...], Lua has no notion of a "main" program: it only works embedded in a host client, called the embedding program or simply the host."  - http://www.lua.org/manual/5.3/manual.html

Some think differently: "Lua is a powerful, dynamic and light-weight programming language. It may be embedded or used as a general-purpose, stand-alone language."
[http://luajit.org/luajit.html]

Having personally used it with success in the latter scenario I find it unhelpful that no effort is spent in pursuing further that direction.
Probably most people interested in that have already moved on.

Stefano

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Coda Highland
On Thu, Feb 25, 2016 at 7:54 AM, Stefano <[hidden email]> wrote:

>
> On 25 Feb 2016 11:15, "Viacheslav Usov" <[hidden email]> wrote:
>>
>> On Thu, Feb 25, 2016 at 9:18 AM, Dirk Laurie <[hidden email]>
>> 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.
>>
>> Given that Lua is officially an "extension language", the scarcity of
>> all-Lua applications should hardly be surprising.
>>
>> Cheers,
>> V.
>>
>> [1] "Lua is an extension programming language [...], Lua has no notion of
>> a "main" program: it only works embedded in a host client, called the
>> embedding program or simply the host."  -
>> http://www.lua.org/manual/5.3/manual.html
>
> Some think differently: "Lua is a powerful, dynamic and light-weight
> programming language. It may be embedded or used as a general-purpose,
> stand-alone language."
> [http://luajit.org/luajit.html]
>
> Having personally used it with success in the latter scenario I find it
> unhelpful that no effort is spent in pursuing further that direction.
> Probably most people interested in that have already moved on.
>
> Stefano

It should be noted that its use as a standalone language is
near-exclusively the domain of Linux, where people don't have a
problem installing dependencies. At least on Windows, you're either
going to have to bundle Lua (at which point a rock doesn't make sense)
or write a wrapper app that embeds Lua (at which point a rock doesn't
make sense). Standalone apps distributed as Lua code aren't going to
see traction on Windows, and unless Microsoft themselves starts
deploying Lua, that's not going to change.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Howard
In reply to this post by Stefano

On Thu, Feb 25, 2016 at 9:54 AM, Stefano <[hidden email]> wrote:
general-purpose, stand-alone language

My primary exposure to Lua is as an embedded scripting language (at work), although it does look like it would be useful as a stand-alone language. I had a friend who was heavy into that about 10 years ago.

However, for a stand-along language for one-off utilities, my default tool of choice is Python. Perhaps the reason a lot of folks aren't interested in Lua as a general-purpose language is the existence of languages like Python, Perl, or even PHP (which I use under duress, but others seem to like).

-- 
Howard Lee Harkness
918-416-1420
Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Peter Aronoff
In reply to this post by Stefano
On Thursday, February 25, 2016 at 03:54PM, Stefano wrote:
> Some think differently: "Lua is a powerful, dynamic and light-weight
> programming language. It may be embedded or used as a general-purpose,
> stand-alone language."
> [http://luajit.org/luajit.html]
>
> Having personally used it with success in the latter scenario I find it
> unhelpful that no effort is spent in pursuing further that direction.
> Probably most people interested in that have already moved on.

Well, I wouldn't say *no effort*. Many of the modules available on LuaRocks
provide various parts of the "battery packs" that larger languages (e.g.
Perl, Python, Ruby) provide out of the box to help people write stand-alone
scripts or larger applications.

I don't necessarily think Lua will take over the stand-alone niche anytime
soon, but I do think that there are lots of other people like you, happily
using it for such purposes. But I may be biased since all the Lua I write
is stand-alone.

P
--
We have not been faced with the need to satisfy someone else's
requirements, and for this freedom we are grateful.
    Dennis Ritchie and Ken Thompson, The UNIX Time-Sharing System

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Viacheslav Usov
In reply to this post by Coda Highland
On Thu, Feb 25, 2016 at 5:09 PM, Coda Highland <[hidden email]> wrote:
 
It should be noted that its use as a standalone language is
near-exclusively the domain of Linux, where people don't have a
problem installing dependencies. At least on Windows, you're either
going to have to bundle Lua (at which point a rock doesn't make sense)
or write a wrapper app that embeds Lua (at which point a rock doesn't
make sense). Standalone apps distributed as Lua code aren't going to
see traction on Windows, and unless Microsoft themselves starts
deploying Lua, that's not going to change.

This is not about Windows vs Linux. Technically skilled users would have no problem using Lua on Windows. This is about technically skilled users vs consumers. Consumers do not typically use Linux on PCs; Linux is mostly used by consumers in non-PC setups, such as Android phones and tables. How would you go about deploying an all-Lua app on a recent stock Android smartphone?

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Tony Papadimitriou
In reply to this post by Stefano
From: [hidden email] Sent: Thursday, February 25, 2016 5:54 PM:
 

>On 25 Feb 2016 11:15, "Viacheslav Usov" <[hidden email]> wrote:
>>
>> On Thu, Feb 25, 2016 at 9:18 AM, Dirk Laurie <[hidden email]> 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.
>>
>> Given that Lua is officially an "extension language", the scarcity of all-Lua applications should hardly be surprising.
>>
>> Cheers,
>> V.
>>
>> [1] "Lua is an extension programming language [...], Lua has no notion of a "main" program: it only works embedded in a host client, called the embedding program or simply the host."  - http://www.lua.org/manual/5.3/manual.html
 
To me, this seems like a case of unfortunate ‘marketing’ strategy from the Lua team... :(
People (new to Lua) in search of a general purpose scripting language are driven away right at that statement (“it only works embedded...”)!  They won’t even bother to read the next few sentences...
 
Further down it reads: “The Lua distribution includes a sample host program called lua, which uses the Lua library to offer a complete, standalone Lua interpreter, for interactive or batch use.”
 
Well, calling it a ‘sample’ implies not for real work but for toying around with the language.  It could be made clearer that this official stand alone interpreter is powerful enough for a whole range of apps, like practically all command-line utilities, while offering a great degree of implicit portability to all platforms with a Lua interpreter.
 
I feel this introduction in the Lua manual could be made clearer to help keep the right people continue reading, while politely sending the rest to greener pastures.
 
(On the other hand, people coming from embedded systems programming, are ‘misled’ to think this is a language specifically designed for embedded systems – and usually for the smaller low-memory ones.  Wrong again.  But they figure it out after a while.)
 
>Some think differently: "Lua is a powerful, dynamic and light-weight programming language. It may be embedded or used as a general-purpose, stand-alone language."
>[<A href="http://luajit.org/luajit.html]">http://luajit.org/luajit.html]
 
This is certainly a more successful approach.
 
>Having personally used it with success in the latter scenario I find it unhelpful that no effort is spent in pursuing further that direction.
>Probably most people interested in that have already moved on.
 
I too use Lua as a stand-alone language with great success, and recommend it to others for that purpose.  It’s ideal for a whole range of apps – mostly command-line utilities for now (only because of lack of standardized GUI libraries).  If an app can be done with Lua, I certainly prefer it to using Python, for example.
 
>Stefano
Tony
Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Tim Caswell
In reply to this post by Viacheslav Usov
With the lit package manager, you can specify that a published package is an application and tell it what bundling framework to use.  Currently this only supports luvi (luajit + libuv + zip asset management in a single binary), but there is no reason it couldn't also support LÖVE, Corona or the other frameworks.

Also to make published application versions stable, lit saves a snapshot of all current dependencies as a git tree hash when publishing.  That way if I want to build luvit v2.0.1 I'll always get the exact same set of lua dependencies, even if some of the dependencies have since changed.  But when I publish a new version of luvit, it will take a new snapshot of the current dependencies so that I don't need to manually update them.  I just need to test to make sure things are working when I publish and they will continue to publish.

Then doing simply `lit make lit://luvit/luvit` will find the latest published luvit release, see it has a tree snapshot of all dependencies, see that it uses a certain version and configuration of luvi, and build a single binary.

-Tim Caswell

On Thu, Feb 25, 2016 at 10:39 AM, Viacheslav Usov <[hidden email]> wrote:
On Thu, Feb 25, 2016 at 5:09 PM, Coda Highland <[hidden email]> wrote:
 
It should be noted that its use as a standalone language is
near-exclusively the domain of Linux, where people don't have a
problem installing dependencies. At least on Windows, you're either
going to have to bundle Lua (at which point a rock doesn't make sense)
or write a wrapper app that embeds Lua (at which point a rock doesn't
make sense). Standalone apps distributed as Lua code aren't going to
see traction on Windows, and unless Microsoft themselves starts
deploying Lua, that's not going to change.

This is not about Windows vs Linux. Technically skilled users would have no problem using Lua on Windows. This is about technically skilled users vs consumers. Consumers do not typically use Linux on PCs; Linux is mostly used by consumers in non-PC setups, such as Android phones and tables. How would you go about deploying an all-Lua app on a recent stock Android smartphone?

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Tim Caswell
I forgot to mention why I brought up this feature of lit.  This is a long-winded way of saying that I agree that there are differences between libraries and applications.

- Libraries want automatic dependency updates without having to re-publish. (preferable using semantic versions so as to not pull in breaking changes, but do include bug fixes.)
- Once published, applications don't want anything to change.  If they want to pull in new dependencies, they will publish a new version.
- Libraries are usually just lua code (or maybe native modules), but always just modules/packages.
- Applications sometimes are run with just `lua` or `luajit`, but often are embedded in some framework that provides better integration with the host system and user interface.

Yes both have a name, publisher, version, files, and metadata and can be published using similar mechanisms, but their intent and use differ a lot.  I feel luarocks aims mostly towards the library use case.  It works for applications that are plain command-line utilities, but not much past that.

On Thu, Feb 25, 2016 at 10:44 AM, Tim Caswell <[hidden email]> wrote:
With the lit package manager, you can specify that a published package is an application and tell it what bundling framework to use.  Currently this only supports luvi (luajit + libuv + zip asset management in a single binary), but there is no reason it couldn't also support LÖVE, Corona or the other frameworks.

Also to make published application versions stable, lit saves a snapshot of all current dependencies as a git tree hash when publishing.  That way if I want to build luvit v2.0.1 I'll always get the exact same set of lua dependencies, even if some of the dependencies have since changed.  But when I publish a new version of luvit, it will take a new snapshot of the current dependencies so that I don't need to manually update them.  I just need to test to make sure things are working when I publish and they will continue to publish.

Then doing simply `lit make lit://luvit/luvit` will find the latest published luvit release, see it has a tree snapshot of all dependencies, see that it uses a certain version and configuration of luvi, and build a single binary.

-Tim Caswell

On Thu, Feb 25, 2016 at 10:39 AM, Viacheslav Usov <[hidden email]> wrote:
On Thu, Feb 25, 2016 at 5:09 PM, Coda Highland <[hidden email]> wrote:
 
It should be noted that its use as a standalone language is
near-exclusively the domain of Linux, where people don't have a
problem installing dependencies. At least on Windows, you're either
going to have to bundle Lua (at which point a rock doesn't make sense)
or write a wrapper app that embeds Lua (at which point a rock doesn't
make sense). Standalone apps distributed as Lua code aren't going to
see traction on Windows, and unless Microsoft themselves starts
deploying Lua, that's not going to change.

This is not about Windows vs Linux. Technically skilled users would have no problem using Lua on Windows. This is about technically skilled users vs consumers. Consumers do not typically use Linux on PCs; Linux is mostly used by consumers in non-PC setups, such as Android phones and tables. How would you go about deploying an all-Lua app on a recent stock Android smartphone?

Cheers,
V.


Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Viacheslav Usov
In reply to this post by Tim Caswell
On Thu, Feb 25, 2016 at 5:44 PM, Tim Caswell <[hidden email]> wrote:

> With the lit package manager, you can specify that a published package is an application and tell it what bundling framework to use.

The sentiment that I tried to address was that one would need to bundle Lua with apps on Windows. Which is almost true, except that "on Windows" should be replaced with "in a consumer environment".

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Hisham
In reply to this post by Dirk Laurie-2
On 25 February 2016 at 05:18, Dirk Laurie <[hidden email]> 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.

Take some time looking at package manager repositories of other
programming languages and you'll see that this observation is in no
way specific to Lua.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Two types of Lua programmer, or two types of Lua code?

Roberto Ierusalimschy
In reply to this post by Tony Papadimitriou
> To me, this seems like a case of unfortunate ‘marketing’ strategy from the Lua team... :(
> People (new to Lua) in search of a general purpose scripting language are driven away right at that statement (“it only works embedded...”)!  They won’t even bother to read the next few sentences...
>
> Further down it reads: “The Lua distribution includes a sample host program called lua, which uses the Lua library to offer a complete, standalone Lua interpreter, for interactive or batch use.”

I would be great if people that use Lua read the manual with that
attention :-)

-- Roberto

123