[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Upstream is not the last word (was Re: [ANN] Lua 5.1.5 (rc1) now available)
- From: Ross Bencina <rossb-lists@...>
- Date: Tue, 14 Feb 2012 16:52:30 +1100
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
- 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
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?