woodsmailbox wrote:

> --- 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.
>

I don't quite understand what you mean by expression power. APL, for
example, was a very expressive language, but a really bad language
nevertheless.

When I mean by expressive is the richness of the data structures handled
by the language. The JavaScript Object and the Lua table are more less
equivalent. The inheritance feature of JavaScript, in my opinion, gives
it an edge over Lua.

>
>> 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.
>

No, that's not good at all. It's a kludge to get around a missing
feature. I don't want to force people to have to invent their own
language layered on top of other languages.

Exception handling is a very strong feature that should be built in to
languages, not layered on by programming convention. C, it can be
argued, has exceptions if every function returns a boolean indicating
whether it worked on not. A certain unmentionable open source database
product does that. It makes the code difficult to read and write and
leads to all sorts of problems.

>
>> 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 :)
>

See above. I don't want to have to invent a language on top of another
language to get around important missing features.

>
>> 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).
>

I'm doing a trial implement of JavaScript designed specifically for
database server side processing. Why? Two reasons. One is that I want
an implementation that support multiple instantiations for efficiency.
The other is that I'm not very enthusiastic about putting a bloated
piece of ancient Netscape in my product. Probably nobody will agree
with either point, which is ok. That said, if there is interest, I'd
open source my implementation.

> 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?
>

Uh, 97.6% of languages do name resolution during compilation.

> 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.
>

That's ridiculous. Lua's table have nothing at all do with relational
tables except a common name. The same argument could by made by
JavaScript by changing the name of "Object" to "Table"

> 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.
>

I have nothing against stored procedures except the existing languages
used for stored procedures. But none of the existing stored procedure
languages (exception: Netfrastructure uses Java as a procedure and
trigger language) come even close to being able to return a cluster of
populated language.

> 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.
>

A better way to do this is to allow free conversion between blobs and
strings. There were reasons I didn't do this originally, but they have
more to do with memory sizes of computers in 1982 than anything relevant
today. Nimbus will probably continue to support blob and clobs for
backwards compatibility, but the "string" and "bytes" data types will
shift automatically between in-record data and distinct blobs.

> 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.
>

--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376