--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jstarkey@...> wrote:

>
> What advantages does Lua have over, say, JavaScript?
>
> Computationally, the languages are quite similar.

If that means expressive power then I have to disagree. Strongly. In fact, it's the
single most big thing of contrast between the two languages. I can expand the
argument if interested.

> JavaScript has exception handling, which Lua does not.

http://www.lua.org/pil/8.4.html
This not good? I can only see a problem of familiarity.

> JavaScript also has object inheritance, which is a very nice thing if you think

multi-instance procedures are an important feature (which I do).

With meta-functions you can easily implement all kinds of OOP in Lua just like you
would do in lisp (eg. see http://lordlaurin.lo.funpic.de/devboard/viewtopic.php?
t=54). However, in a stored proc I'd rather have functional programming (expressive
power) rather than OOP, since is data manipulation rather than heavy process
programming that I'm most likely be doing in a sp. Besides I thought relational
weenies abhor OOP for these kinds of things :)

> Both languages are designed for embedding, so I'd call that a draw.

I was referring more to the current Lua implementation that is designed for
embedding (i.e. the binding API) more than the language itself. Which Javascript
interpreter are you referring to which has a similar quality? Webkit's,
SpiderMonkey? I wouldn't take implementing a new one too serious. Also, it's easier
to bind Lua to a static-typed environment than Javascript (will expand if
interested).

About size/speed of both Lua and Javascript -- I wouldn't worry a bit, they're as
fast and small as you can get. About attribute hashing -- is there any other way?

Now back to my advocacy: my reason for Lua is the good impedance match with the
relational model because of a core feature: tables. Not even php (indexed arrays of
assoc. arrays?), python (lists of dictionaries??), javascript (??) is so close.

But before I continue, let's define the problem domain, because I read someone
already thinking whether another pl language has any use at all.

I can see two problem domains:
1) complex data manipulation (i.e. algorithms) that take complex/large input and
have complex/large output. I'd love to do'em with stored procs: transactional and
close to the data.
2) accessing external resources through built-in/external libraries, blending them
with business data, and process them with sql. I'd love to do some
joining/grouping/filtering upon a bunch of directories, or return the contents of a
file on the filesystem as a blob field so I can get blobs out of the database
without the client app to even notice, etc. etc. -- your imagination is the limit.

For 1), pl/SQL is not nearly enough (for once, because you can only have primitives
in the local scope). You might get somewhere with local temporary tables, sql
functions, etc., but not very far.

For 2), you might get away with pl/SQL if you had an API for implementing virtual
tables (and someone would bother to implement a nice library for that)... that would
be your gateway towards external resources, but then again, I'd rather code that in
a hi-level language in a stored proc. I never liked binary UDFs and I don't think
I'll like a binary binding for virtual tables.

Glad I've sorted that one out :)

Now just a curiosity hope I won't offend anyone with: Is anybody actually really
interested in binding a hi-level language to the pl engine, be it Javascript, Lua or
whatever?

Regards,
Cosmin.