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

[Ken Anderson <address@hidden>]

It isn't clear to me from your web page, how score is computed.
It looks like it's related to the number of characters, or tokens.

I think token's is better than characters, but i think counting lines is 
better than counting tokens.  This would let "puts("Hello World") and
"System.out.println("Hellow World");"
to have the same score, of 1.

More verbose languages will take more lines eventually.

There are conventions that take more lines than others.  For example, in 
Java, i don't mind writing the obvious getter and setter methods on one 
line, while others right them in 3 or 4, of what i'd call "airy" lines.  I 
prefer to see as much code in an Emacs buffer as i can.

Comparing Java to Jython, if you don't count lines in Java that only 
contain "}" and white space, you'll move Java closer to Jython, but Jython 
has other ways to be compact.

Your nice compiling example is compact for several reasons.  One is nice 
library support like .sub() and system().  Perhaps we assume that a 
comparable library exist in another language.

A nice test might be to build library for building applications.  I have 
one in Jscheme that can build a java application in about 50 lines of code.
Here is a version of you see compiling example that Tim Hickey and i came 
up with:

(define (needsRecompile f o)
   (if (or (not (.exists o)) (<= (.lastModified o) (.lastModified f)))

(define (isCfile f) (.endsWith (.getName f) ".c"))

(define (// text pattern replace)
   (.replaceFirst (.matcher (Pattern.compile pattern) (.toString text))
                 replace))

(define (deep-cc dir)
   (for-each
    (lambda (c)
      (let ((o (File. (// c ".c$" ".o"))))
        (if (needsRecompile c o)
            (begin (display {compiling [c] to [o]\n})
                   (system {cc -c [c] -o [o]})))))
    (filesBelow dir isCFile)))

k
At 06:50 PM 9/24/2002, Pixel wrote:
>Jakub Travnik <J.Travnik@sh.cvut.cz> writes:
>
>[...]
>
> > I see some bias in following code:
> >
> > | sh        |a=1; b=2; echo "$a + $b = $[$a + $b]"                  |
> > |-----------+-------------------------------------------------------|
> > | Ruby      |a = 1; b = 2; puts "#{a} + #{b} = #{a+b}"              |
> > |-----------+-------------------------------------------------------|
> > | Perl      |$a = 1; $b = 2; print "$a + $b = ", $a + $b, "\n"      |
> >
> > Why assignment in ruby and perl (and some others) have redundant spaces?
> > I'm just used to skip those in my code.
>
>ok, i remove them.
>
> >
> > This leads me to other question: Can we sacrifice readability for size
> > in such comparison? Or we can measure number of language tokens
> > instead of characters (e.g. identifier count as one, brace count as
> > one, mandatory space count as one, ...)? I would prefer this kind
> > of counting.
>
>distinguishing mandatory spaces is not easy across languages
>
>I thought about tagging non-mandatory spaces, but there are too many
>
>about counting tokens:
>- variables names are the same for each snippets, so no pb
>- library function names difference in length can be quite important.
>   should System.Console.WriteLine be considered as 1 token? 5 tokens?
>   whereas scheme's "read-string!/partial" or "date->time-monotonic" be
>   1 token ?
>
>[...]
>
> > There is C compiler that knows shebang and can do some form of bounds
> > checking. It is tcc.  It is targeted for scripting since program is
> > compiled directly to RAM memory without intermediate files (it cannot
> > compile to file). It is also very small, under 100K bytes.
> >
> > Here is its description from debian package:
> >
> > tcc - Tiny C Compiler - The Smallest ANSI C compiler
>
>ok, i replace gcc with tcc
>
>[...]
>
> > BTW: Shebang is 15 points and REPL 5 points in test.  I would honor
> > REPL more points than 5 since it affect way how scripts are developed
> > (especially when introspection is available, e.g. in ruby I use
> > method "methods" in IRB much when developing).
>
>I would say debuggers. A debugger with full REPL power is nice.
>
>how do people debug in python? do they really do
>% python /usr/lib/python2.2/pdb.py prog.py
>??