Re: Lua libraries

[RLake@...]

David Jeske escribió:

> My impression is that the "lua standard library workshop" is really
> about just that, changes to the lua standard library. It's still going
> to be built into lua, and lua is still going to be primarily an
> embedded language.

I hope that is true.

> I believe that any attempt to make a widespread set of standard
> libraries for Lua will probably be kludgy.

I personally think that any attempt to make a widespread set of
standard libraries for any programming language tends to be kludgy.
However, that doesn't make them unuseful. It can make them hard
to integrate with each other. This is particularly true for standard
object libraries IMHO: while I won't claim to be an expert, from what
I've seen, object libraries do not tend to realise the promise of
reusable code to the extent that we might have dreamed about.

> All the intersting
>"prototyped objects" features which make Lua interesting for
> exploratory embedded programming are a problem when it comes to
> packaging up a bunch of code in a standard way.

I wouldn't have put it that way. The fact that Lua does not come with
much in the way of standards makes it difficult to package standards.
This is not at all related to prototypes. One has only to look at the
standard
"libraries" (or templates) which come/came with NewtonScript (another
prototype-object language) to see the possibilities. Personally, if I had
the time and hardware available, I would love to reimplement the
NewtonScript
display model in Lua. Walter Smith is quite eloquent about the advantages
that
prototyping gives in producing graphical applications, but I suspect that
one
has to experience the difference to appreciate it.

Of course, NewtonScript is/was a tad more structured (but just a tad :-)

Prototypes are good at building components. Components are arguably a
higher-level construct than objects, although the distinction may not
be very precise. Templated components do seem to be reusable and
integratable;
however, they certainly restrict flexibility. This is not always a bad
thing.

> First, there would be
> discussion about standardizing on one class-ish model, then there
> would be talk of adding exceptions to Lua, and at the end we'd have
> something which was basically like Perl or Python with 1/10 of the
> available modules.

That is a very harsh judgement, no? But there may be a grain of truth to
it. :-)

I would like to hope that the discussion proceeds with a view to retaining
that
which is special about Lua, and not with a view to making Lua into Python
or
Perl. Lua is not Python; I'm sure that both have their place. There is,
dare I
say it, a certain Zen to any programming language and getting your head
into
it is critical to making your life simpler. Or if not, using a programming
language that suits your way of thinking, or your particular problem
domain.

As far as "talk of adding exceptions to Lua", or "one class-ish model",
neither
of these really appeal to me. I think that Lua has adequate mechanisms for
doing what I want it to do with object-ish things. It is maybe slightly
lacking
in control structures, but I personally would like to see a building block
at a
slightly lower level than exceptions. (Non-local exits as first-class
functional
objects, to be precise.) So now I've contributed to the "talk" :-)

My S/0.02...