#20 - Probably a matter of taste. I do like being able to grasp a little
information about an identifier without looking up its declaration or
whatever.

#21 - I used to feel the same way, but I decided I was just being
overly traditionalist (read: fuddy-duddy). The more I think about it,
the more I like the sophistication of a language processor that can
determine whether a word is being used in a "standard" sense or in
a user-defined sense. After all, determining meaning of a word by
context is not that much different from the ordinary concept of scoping,
where many variables can have the same name, and meaning is
determined by context.

#29 - Yes, ksh can do a lot, but I don't think as a language it is in a
league
with Ruby. Admittedly, it is not optimal to use it as a shell, because of
the
inconvenience of executing external programs and so on. One doesn't
always want to put backticks around everything...

Hal


----- Original Message -----
From: David Douthitt <DDouthitt / cuna.com>
To: ruby-talk ML <ruby-talk / netlab.co.jp>
Sent: Tuesday, August 08, 2000 8:32 AM
Subject: [ruby-talk:04350] Re: Thirty-seven Reasons [Hal Fulton]Love[s] Ruby




I like these 37 reasons!  Anyway, I agreed with almost (almost) all the
reasons.....

REASON 20
20.  It uses punctuation and capitalization creatively. A method
returning a Boolean result (though Ruby doesn't call it that) is
typically ended with a question mark, and the more destructive,
data-modifying methods are named with an exclamation point. Simple,
informative, and intuitive. All constants, including class names,
start with capital letters. All object attributes start with an @
sign. This has the pragmatism of the old "Hungarian notation" without
the eye-jarring ugliness.

To me this is a DRAWBACK to Ruby - capitalization should be solely at the
descretion of the user.  It is annoying to find that the error is being
caused because the Ruby interpreter insists that Foo and foo are different
types (yes types!).  Some languages (Eiffel and Sather I think) require all
sorts of funny capitalization requirements, which were an instant turn-off
for me.  Either foo and Foo should be identical (case-insensitivity) or foo
and Foo should be separate (case sensitivity) but variable type, class, or
other indicator should NOT be based on capitalization.

Let me get off my soapbox now - my apologies for ranting so.

REASON 21
21.  Reserved words aren't. It's perfectly allowable to use an
identifier that is a so-called "reserved word" as long as the parser
doesn't perceive an amibiguity. This is a breath of fresh air.

It is?  I don't think anyone should use reserved words as normal variables.
A compiler or interpreter writer should almost disallow reserved words as a
matter of principle - though in extreme conditions, it might be useful to
use them.

REASON 29
29.  It can be used interactively. Conceivably it could be used as a
sort of "Kornshell squared."

Oh, really?  I don't know..... ksh can do a LOT.  And what about scsh
(Scheme Shell)?  Another language for me to learn :-)