[JDEV] Client scriping language

[Scott Robinson]

I've been looking at the scripting language issue a bit closer and have been
forced to look at a few hard facts.

Before launching into my newest textual drainage, I will summarize in saying
every usable scripting language under the sun has been suggested. However,
after looking at each one closely, I have came down to deciding between the
following three as my recommendation: Python and ECMAScript
(Javascript).

The problem with deciding a scriping language for a general purpose
application is one needs to know, ahead of time, what type of portability
issues will arise and what the language is actually needed for. The question
that kicked the whole debate off was "what scripting language will we use?"
(not verbatim) No limit, no reference, and no use was given. In a response
post, I suggested that we link the scripting language into the client and
have it control the UI. Further posts have hinted towards the language
portable and transported between the clients themselves. It is these two
purposes that I have in mind.

Of the top contenters, Perl and Java were immediately suggested. Both have
the benefit of being implemented on targetted architectures. Both are able
to be transported over the net quite easily with a minimal (or no) "binary"
modification. However, both have been ruled out. Perl requires the interpreter
and varies significantly between architectures. To much for the needs Jabber
has of it. Java is over-weight and impossible to embed into an application
that wants to keep any type of light-weight. NOTE: I would keep an eye on
JabberBeans. An all Java client has its niche and I will certainly be on the
testing group for it!

Guile seems to enjoy a bit of support. It has two advantages running in that
it is pure GNU and it has plenty of developer support. However, Guile is
Scheme. Scheme is a mathematical language, definately not designed for what
we're searching for.

TCL/Tk is far outside what we need. I will go no further.

I also looked at a variety of bytecode ANSI C interpreters. While offering a
simplicity and code "linkage" that no other language offers, all are far to
immature. Enjoyable within a non-secure environment, all of the ANSI C
interpreters I was able to find offer no backlog or track record for us to
use.

After I ruled out the other scripting languages, I am left with Python and
ECMAScript. Both enjoy considerable developer support. Both have generous
licensing agreements and will be easily implemented within a Jabber client.
However both have their cons as well. Python would be very difficult to
transport over the network as a scripting language. Once compiled, it seems
to be much more platform specific than ECMAScript. ECMAScript, though, has
its own faults. Definately created with speed and efficiency with a
afterthought, ECMAScript is a bloated scripting language. Also, there are so
many implementations of it, it would be difficult to not only decide on one
but use any of the ones I found with any efficiency.

It seems I'm forced to choose between Python and ECMAScript only because
they are the lesser of the many daemons. Unfortunatly, I can't. I leave it
up to the implementor of the code to, in the end, make the choice.

I will be the first to admit I may have been a bit hard on most of the
languages, but I'm a tough guy. + my opinion doesn't mean much and tomorrow
I will probably make a radical push for something else. So, as always, take
my opinion with a can full of salt and remember "Scott's on crack."

Scott.

P.S. Feel free to correct any and all incorrect statements and horrible
generalizations in my e-mail. I've made quite a number of them, many even I
feel to be mis-representations of the "truth." However, it's now how you got
there, but the answer that really matters. Hold on a second...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/19990806/8ffff77c/attachment-0002.pgp>