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

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

>    Runtime.getRuntime().exec("find /").waitFor();

Under Sun JVM v1.3.1 this seems to hang, and I don't know enough about it to
know why.  Waiting for an output consumer maybe?  However, executing the
same command with the other approach you gave:

    BufferedReader input = new BufferedReader(new InputStreamReader(
        Runtime.getRuntime().exec("find /").getInputStream()));
    while ((String line = input.readLine()) != null)
      System.out.println(line);

...worked just fine on a volume with 21,216 files.  Elapsed time, 10.8
seconds, using "java TestStream > junk"; 13.4 secs with output to a
minimized console window; 36.5 secs with output to a foreground console
window.

> > 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.
>
> hum, this need proof. IMO a good shell scripting language can also
> nicely support implementation of abstractions. eg: Ruby

That's why I said "pure" shell scripting languages.  I'm thinking sh, ksh,
bash.  Ruby is more of a general purpose scripting language, along with
Python, Perl etc.

> i don't agree. What you get in that case is whether the language
> without including the libraries is good for scripting.

Yes, but you can find that out simply by reading the promotional info for a
given language - you don't need to run tests.  You're really just asking
whether a language has explicit shell scripting features built in.

The SOP tests could be useful to compare languages that have such support,
including Perl, Python, Ruby, and the *sh languages; but they seem fairly
pointless when applied to pure ML, Haskell, Java, C, etc.  Even many
Scheme/Lisp implementations, which I would think are good candidates for
scripting (see SCSH), would suffer if they're not allowed to use
non-standard libraries.

Re your ideal feature lists, I agree with Dan W. that you need to be careful
to concentrate on what can be achieved rather than how it's achieved, since
otherwise you may end up simply imposing your preferred paradigm.

>     Without anonymous functions, having simple things like "finding an
>     element in a list" or "a custom sort" is tedious. For example Java
>     doesn't even have a "find" method, acknowledging the difficulty to
>     use "find" without anonymous functions.

You can use anonymous inner classes to achieve this in Java, e.g. given an
interface like:

	interface UnaryPredicate { boolean apply(Object o); }

...you can implement code to support this sort of thing:

	someCollection.find(new UnaryPredicate() {
		public boolean apply(Object elem) {
			return elem.someProperty() == someMatchValue;
		}});

I think the biggest reason you don't see more of this in Java code is that
anonymous inner classes were a late addition to the language, which haven't
really been exploited or catered for in the libraries; and the approach is
also somewhat foreign to much of the Java developer population, although of
course that's a bit self-fulfilling.

Anton