Re: Upstream is not the last word (was Re: [ANN] Lua 5.1.5 (rc1) now available)

[Ross Bencina <rossb-lists@...>]

On 14/02/2012 5:45 AM, Axel Kittenberger wrote:
> I don't get it what you are
> aiming at, or just don't see through it through the badly written
> text.

I'm going to attempt an answer, from my perspective:

Use case #1: application development language

Currently I use Lua embedded in my app for internal projects. I use it 
to implement customised application logic for specific projects. My 
impression is that this is how it's used for many projects -- as an 
internally embeded language, much like any other application development 
language. The only developers that see (or care about) the Lua code are 
the other project developers.

In this scenario, having a common base library would serve the following 
aims:

- It would make it easier for new developers to join in, because they 
would be familiar with the base library.

- It would make starting a new project like this much easier because I 
wouldn't have to make basic design decisions like "how should objects 
work" or "where can I find a set of classes for basic stuff that I expect".

Maybe this "common base" is only 100 LoC, I don't know, but it would be 
much better starting point for new developers than "every time I embed 
lua I have to make all these design decisions about my language 
environment, and write a bunch of container classes to give the expected 
semantics".


Use case #2: user extension language

This is the more imporant use-case from my point of view. If I embed Lua 
as an user extension language (which I would like to consider doing), I 
would be providing my users with something called "Lua" that they can 
use to extend my app. However, there is a bunch of basic stuff that they 
will need (object support, basic data structures, etc) that I will need 
to provide them, because Lua doesn't. In this sense, what I'm providing 
is something called "Lua" but it could easily be incompatible with every 
other "Lua" the user has ever seen -- depending on how I implement 
certain basic runtime features.

In this scenario, a common base library would serve the end users, and 
the app developer:

- As an embedder I don't have to make basic decisions like how an object 
is implemented. I just do it "the common base way".

- The end users would get familiar facilities that they have used in 
other "Lua" environments. Rather than confusion: "it works like this in 
this app, but in this other "Lua" app it works like that".

Sure, there could be design decisions I decide to break, but right now I 
am forced to research and decide on everything myself.


Don't get me wrong, I'm not criticising core-Lua at all. I'm a big fan 
of the current design approach. However, without a common base library 
it is confusing and unsettling to embed -- there is too much 
infrastructure stuff I have to do myself -- when I really want to be 
getting on with writing application code.


I agree with Jay that forming a minimal common base out of existing 
best-practice would be the ideal. I'm no Lua expert, so I'm not the one 
to write it, but I would certainly deploy it.

Note here I'm not talking about runtime facilities (like luvit) or even 
about domain-specific infrastructure libraries (like XML libraries, 
JSON, logging) .. just basic stuff needed to organise and express medium 
size software systems: basic data abstractions, an object system, 
whatever other tools are commonly needed.

For use case #1 above (developing) it probably doesn't matter, people 
can do what they like, but for use case #2 (user extension) I really 
don't want to wear the "object system and language library designer" hat 
and be held accountable by my users of how such basic facilities work -- 
I'm more than happy to do it the "standard base way".

Does that make sense?

Ross.