RE: Scriptometer: measuring the ease of SOP (Script Oriented Programming) of programming languages

["Anton van Straaten" <address@hidden>]

I'm answering backwards to clarify my position.

> In any case, I don't think this salvages Java-the-Language!

I agree that the Java language itself is not a scripting language, let alone
a good one.  However, I'm really suggesting that the definition of
"Script-Oriented Programming" should be expanded.  Many existing products
and open source applications support scripting of Java applications, i.e.
writing script code that manipulates a library of application objects that
are implemented in Java.  This works very well - much better, for example,
than any solution to script C that I've seen.

The broader definition of Script-Oriented Programming I have in mind would
look at the following (minimum) dimensions:

1. Is it a scripting language, i.e. can script-like code be written in it?

2. How well does it support being externally scripted by some other
language, possibly including a script-oriented version of itself?

2a.  How good is the support it provides to the implementor of an external
scripting language?

Your current SOP test only addresses (1).  Adding the other dimensions in,
Java would do much better against e.g. C, as in the following completely
made up table:

   |  C  | Java
---+-----+------
 1:| -60 | -66
 2:|  0  |  85
2a:|  0  |  92

Factors which affect scores for 2 & 2a would be the presence of garbage
collection, support for dynamic code loading and reloading, reflection, and
more which I touch on below.

> 1. I don't know much about this. All I can say is that JVM is
> dynamically typed and reflexive and this helps. A pb may be
> performance.

In my experience, performance is not an issue in typical commercial
applications - especially compared to existing scripting languages, which
aren't always speed demons themselves.  One example I have some experience
with is the Resin web application server, which supports server-side
Javascript which is compiled to Java source and thus to bytecode.  This is
done automatically by the server, so the perception from the developer's POV
is that of an interpretive environment on a par with PHP or ASP - you make a
change to the source of a page and it takes effect immediately.  This relies
on Java's dynamic code loading (and reloading) ability.  The end result
outperforms ASP in tests, presumably because ASP is not similarly compiled.
(I imagine ASP.NET would perform better, since it does get compiled.)

I've also worked with Beanshell, in applications which use it essentially as
an "eval" capability for Java.  In cases like this, any performance hit from
interpretation is expected, and not usually of much concern.

These approaches seem to be gaining wider commercial acceptance, e.g. BEA
has apparently begun including Beanshell (which is LGPL) with its Weblogic
application server.

> 2. I don't know if "a standardized high-level object model" is so
> much an advantage when the scripting language is not OO.

The object model is what makes it possible for the scripting language to
script objects implemented in the "primary" language, which in this case is
Java.  It wouldn't be an advantage if the goal were to code primarily in the
scripting language, but if the goal is to use script to control objects
implemented in the primary language, then a common object model is a big
advantage.

For this purpose, it's not a big deal if the scripting language isn't
inherently OO - for example, the various Schemes for the JVM provide simple
ways to access and create Java objects.  This is typically a small
traditional API, although JScheme for example is more creative:
http://jscheme.sourceforge.net/jscheme/doc/javadot.html

> I don't know either if having two different garbage collectors
> is better than having only one gc interfacing with C. When
> extending Ruby or OCaml in C, you don't have to care about
> garbage collection.

I'm not sure what you're referring to.  None of the JVM scripting languages
I've worked with have two garbage collectors - they all rely on JVM
collection.

I previously mentioned garbage collection in the context of C, because when
C itself is evaluated as a scripting language, memory management would
either be manual or require an add-on solution.  I'm saying the presence of
a collector in the JVM and the ability for JVM scripting languages to rely
on it, is a scriptability benefit for Java and/or the JVM.

Anton