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

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

>     BufferedReader input = new BufferedReader(new InputStreamReader(
>         Runtime.getRuntime().exec("echo done").getInputStream()
>     ));
>     String line;
>     while ((line = input.readLine()) != null)
>       System.out.println(line);
>
> but this doesn't work for commands writing too many things on stderr
> (at least on gcj)

I don't think that gcj makes a good platform for testing Java's
capabilities, unless you're simply using it to produce .class files which
run under a regular JVM.  I don't know whether this particular code would
work better under a JVM, but it might.  What would be a good test command to
pass to exec()?  I'll try it.

Looking at the substantial difference in conciseness between 'false || echo
"false failed" 1>&2' and something like the above, it seems clear that a
major issue is simply that shell scripting languages are domain-specific,
and thus have significant syntactic, semantic and library support for
typical shell scripting operations.  In a sense, at least some of your tests
are proving that "shell scripting languages are the best languages for shell
scripting", which isn't all that informative.

In a more general-purpose language, script-like operations are going to
require a support library in order to be able to compete.  Although I
understand the logic of wanting to work with the raw, standard language,
that limits the usefulness of the tests, IMO.  Of course, it comes down to
what exactly the tests are trying to measure.

For example, it would take only a trivial amount of code to provide support
for something more like this in Java:

   out.write(Shell.exec("echo done").getInputStream());

Not quite as concise as shell script, but much closer.  Note that
"out.write" or similar is commonly used in Java-based web scripting &
servlet environments.

Another way to put this argument would be as follows: general-purpose
languages provide much better support for implementation of abstractions
than do the pure shell scripting languages.  To disallow the use of
appropriate abstractions in tests like these gives a skewed result, at best.

Anton