lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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?