Programming Languages Wiki Ruby entry

http://cliki.tunes.org/Ruby

has an odd (to my mind) first paragraph

A interpreted object-oriented programming language based on the
concepts of Smalltalk 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. It interestingly supports continuations, although
this is not an advertised feature.

“oriented to command-line processing almost exclusively”? Doesn’t
sound like Ruby to me. I’m not even sure what this means – is it
"for implementing shells" or “Ruby is little more than Getopt”?

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

Maybe someone more on the academic side of computer science can
understand what was really meant here, and suggest mods to this. I
think CLU and Perl probably should be mentioned near Smalltalk…

    Hugh

http://cliki.tunes.org/Ruby

has an odd (to my mind) first paragraph

A interpreted object-oriented programming language based on the
concepts of Smalltalk 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. It interestingly supports continuations, although
this is not an advertised feature.

This does sound strange to me.

“oriented to command-line processing almost exclusively”? Doesn’t
sound like Ruby to me. I’m not even sure what this means – is it
“for implementing shells” or “Ruby is little more than Getopt”?

I wonder if they mean it doesn’t have an IDE like
Smalltalk’s? I don’t know Smalltalk, but I’ve
heard the IDE is a big part of it.

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

Probably they saw the Perl side of Ruby and made
assumptions based on that.

Maybe someone more on the academic side of computer science can
understand what was really meant here, and suggest mods to this. I
think CLU and Perl probably should be mentioned near Smalltalk…

This should be a group effort perhaps.

Hal

···

----- Original Message -----
From: “Hugh Sasse Staff Elec Eng” hgs@dmu.ac.uk
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Thursday, April 10, 2003 7:17 AM
Subject: Programming Languages Wiki Ruby entry.

Saluton!

  • Hugh Sasse Staff Elec Eng hgs@dmu.ac.uk; 2003-04-10, 13:22 UTC:
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

In article <20030410172214.GA1378@jupp%gmx.de>, jupp@gmx.de says…

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

“test before” is the default and could have been omitted.

varying i from 1 by 1
until i = 5

add i, 1 giving j

This line seems to be redundant.

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

I think it’s perfectly readable. Nice work; I don’t think too many
people can write COBOL and Ruby.

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?

No, but then I’d probably figure out a way to use a sort method. COBOL
has a sort verb, too, but it would probably be awkward in this
situation.

COBOL has its place and is here to stay. I’m not sure you’d want to
write a banking application in Ruby; there are performance
considerations if nothing else.

It would be interesting to speculate on what COBOL would be like if it
were designed today. Would it be less verbose? Possibly. Would it be
a substitute for, say, Ruby? No, not any more than Ruby could take the
place of COBOL.

Louis Krupp