[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

> >     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.

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


> 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());

or even better for this pb

  system("echo done")

which would take care of *both* stdout & stderr


> 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

there *are* conflicting things between general purpose and shell
scripting. here are features good for scripting, but bad for general
purpose: (IMO of course :)

- be failthrough, give a meaning to everything (think perl). 
  eg: auto-growing, auto-created arrays/hashes
- blurring string/number a la Perl (is that really good?)
- poluting the namespace 
  (not a such a pb with good namespace handling)
- dynamic typing (?)
- get rid of exception declarations (think Java)
- get rid of control access (public/private/...)

but there are also features that do not conflict with a general
purpose language (yet again, IMO!):

- at least have a short name for a "print" function,
  it need not be tied to stdout, eg: "display" in smalltalk
  (as perlists say, use huffman coding... ruby has function "p" !)
- have a powerful printing function 
  eg: interpolated strings, printf/format
- have an easily available function to convert an object to a string
  to_s(ruby)/str(python)/Dumper(perl) function
- a complete system library, including things like system, ``...
- a reasonable string library
- powerful lists/arrays having both functionalities
    When you are using a list, it doesn't mean you don't need
    indexing. Conversely you sometimes need to remove some elements in
    an array. Scripting languages (perl...) have blurred lists and
    arrays successfully (in term of expressivity). Even better, one
    should be able to easily switch from an list implementation to an
    array implementation. One could even dream of an optimizing
    compiler which would make the choice on its own...

    (on this subject i highly recommend http://citeseer.nj.nec.com/peytonjones97bulk.html)

- do not have the file name tied to a name in the source file 
  (think Java). If there must be a link between the source file name
  and some class/module, why not do it *automatically* (think
- a powerful debugger
- an interpreter/compiler that is fast for small programs

> To disallow the use of
> appropriate abstractions in tests like these gives a skewed result, at best.

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

i advocate that libraries (esp. strings, lists..., but also I/O) are
an important part of a language.

about libraries (IMO!):

    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.