---------- Original Message -----------
From: Jim Starkey <jstarkey@...>

> Doable, yes. But why? The main claim to Javascript is its ability to
> interact with the document object model (DOM) of a browser which, of
> course, neither exists nor has a counter part in the server. It is
> cheap to parse and interpret and runs in a sandbox, all good things for
> an embedded language. So my question is "why Javascript?" What
> problems does it address/solve?

------- End of Original Message -------

(language)
That's a little reductionist. Javascript is used to interact with the DOM in browsers, but other
languages (e.g. vbscript) can do that as well. Javascript, like Lua and Python, is designed as an
embeddable, extensible "glue" language for a variety of environments. If picking between languages
to add to Firebird, it should be judged on the merits of the language itself. But first you have to
decide why you would add a new language to the db engine at all.

(learn from others)
PostgreSQL went and built in the ability to write triggers, procedures, etc. in a variety of
languages (and in the process, had to split triggers into two parts: the trigger definition, and
the underlying written-in-any-language function that it invokes -- necessary, but messy); can we
find out from them how useful that turned out to be? Do their customers who code the middle tier in
Perl also prefer to code triggers in pl/Perl? Does it confuse them? Do they generate code, and have
Perl generating pl/Perl, with scary escape-sequence stuff everywhere? (I've recently been writing
PSQL to generate PSQL, so I'm sensitive to the issue.) Do they have stats on how often people use
an alternative to pl/pgSQL? (It's a bit like their user-defined types: great in theory, but is
anybody using them for anything? If so, what? They only list GIS and FTS as available extension
downloads.)

(usefulness)
Their documentation hints that the benefits of pl/Tcl and pl/Perl are the built-in string
functionality in those languages (most of which you could add to PSQL, or pl/pgSQL, by defining
UDF's to useful C functions); other functionality seems to be restricted because of safe/unsafe
code considerations. What does Javascript bring to the table here? (It brings closures and other
handy tricks, but see below, you still have to worry about the interface between the system and the
scripting language.)

(api after all)
The pl/Python docs, for example, indicate there's some weirdness with passing tuples around, which
brings me to my concern: it doesn't matter which other (interpreted or not) languages are made
available, it's the functionality of the language that matters, and ultimately that functionality
comes down to built-in functions, and then whatever the engine exposes to it. If you add pl/Python,
but passing "row" objects around is painful, that doesn't gain you anything over the original psql
or pl/pgSQL language, where it was already painful (e.g. passing NEW or OLD to a procedure from
within a trigger). If exception handling isn't standardized across language boundaries, your
interoperability drops off. If functions in some languages can't return result sets (only scalar
values), your consistency disappears, and if they can't do the equivalent of SUSPEND, you've got
potential performance issues too. (I'm looking at you, current C UDF implementation!) If the engine
doesn't globally provide a means to do these things, new scripting languages are just a waste of
time. They're syntactic sugar on top of the engine itself, but that's all they are -- sugar. And if
you add this functionality to the engine, and therefore to PSQL (favorite son), well ... what's the
point in having several languages, other than being able to use {} or indentation instead of
BEGIN/END?

This is probably why we've stuck with just one language in the browser -- not because we had to,
but because it was sufficient to access all the DOM functionality exposed by the browsers; adding
new langauges isn't terribly helpful to 99% of the programmers out there, but adding functionality
to the DOM itself would be. That's not to say that Javascript isn't a good language, it's actually
pretty cool, but I don't think that's why it's stayed at the fore-front of client-side web
technology. It works well enough, and that's that.

-Philip