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

[Pixel <address@hidden>]

"Anton van Straaten" <anton@appsolutions.com> writes:

> Something to consider is to what extent a language makes it easy to
> integrate scripting, even if its native support isn't that great.  I'm
> thinking of Java here (possibly C# also) - despite the poor scriptability
> score that pure Java gets, there are a number of more scripting-friendly
> language implementations that integrate very tightly with Java's object
> model, including Javascript, Python, various Schemes, and BeanShell.  The
> latter is actually an optionally typed scriptable version of Java itself.
> All of these languages support REPLs.
> 
> All of these ought to score a lot higher on SOP tests, but since they all
> support implementing and scripting of Java objects, and are typically what a
> Java programmer would use to achieve scripting functionality, doesn't that
> indicate that Java is actually a better language for this purpose than it
> might first appear?

I'd rather say that Java provides an extensive base library for
scripting language to use

> Languages like C don't lend themselves as well to this sort of thing, mainly
> I think because they don't provide a standardized high-level object model
> (not to mention garbage collection) for foreign environments to leverage.
> Features like reflection and runtime class loading also help scriptability.

I think we should be talking about the JVM instead of Java. JVM
doesn't _imply_ Java. Just like .NET doesn't _imply_ C#.


The question becomes:

1. is the JVM (or .NET) a nice bytecode to build scripting languages
on top of it?

2. is the JVM (or .NET) easy to interface with to access the extensive
library available for the JVM (or .NET)? Is it easier than interfacing
with a C library?


Answers (mostly wild guesses, many people know better and will
hopefully say better):

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.

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


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