Saluton!

* Hugh Sasse Staff Elec Eng <hgs / dmu.ac.uk>; 2003-04-10, 13:22 UTC:
> <quote>
> A interpreted object-oriented programming language based on the
> concepts of Smalltalk

That sounds reasonable.

> while being oriented to command-line processing almost exclusively,
> so it has a terse punctuation-style syntax with libraries centered
> around text-processing and Unix shell functionality.

That statement correctly states facts but it is meaningless. You
could also state that C(++) is a programming language that is
oriented to direct memory access because that (besides parsing
command line arguments) is the only interaction C(++) is capable of
without using libraries.

C(++) has a much terser punctuation-style syntax with libraries that
are also centered around text-processing and Unix shell
functionality.

> "it has a terse punctuation-style syntax"?  Compared with what?
> [COBOL? :-)]

According to me, COBOL should be read as Common Babble Oriented
Language and even this language does use characters in its syntax
that are neither digits nor letters.

For programs that can easily be read COBOL's syntax does a bad job
because it is too verbose. At the other end of the spectrum we find
brainfuck - nomen est omen. The truth lies somewhere in the middle.

It is similar to good mathematical texts where the author keeps a
balance between written text and mathematical symbols. A lot of prosa
indicates that the author may not be able to provide a formal equi-
valent of his thoughts while too much of mathematical symbols may
indicate that he is not sure what the implications of his formal
manipulation are. Passages where one finds the former or the latter
often are precisely those that invalidate a proof or at least require
some additional work.

C allows for very complex agglomerates of ++, --, * that at first,
second and third sight look okay but at fourth sight reveal some
unexpected (and perhaps dangerous) side effects. COBOL on the other
hand requires you to write lengthy prosa that is unreadable due to
its length:

perform test before
varying i from 1 by 1
until i = 5

  add i, 1 giving j
  perform test before varying j
  from i by 1
  until j > 5

    if cash(i) > cash(j) then
       move branch(i) to tmp1
       move cash(i)   to tmp2

       move branch(j) to branch(i)
       move cash(j)   to cash(i)

       move tmp1 to branch(j)
       move tmp2 to cash(j)
    end-if
  end-perform
end-perform

In Ruby you would probably write this as:

1.upto(5) { |i|
  i.upto(5) { |j|
    if cash[i] > cash[j]
      branch[i], branch[j] = branch[j], branch[i]
      cash[i],   cash[j]   = cash[j],   cash[i]
    end
  }
}

You would not consider using temporary variables, would you?

Gis,

Josef 'Jupp' Schugt