----- Original Message -----
From: "William Djaja Tjokroaminata" <billtj / z.glue.umd.edu>


> Hi,
>
> [...]
>
> Which brings us to the second point.  Perl was kind of a
> "maximalist" language; there are almost always more than one way to do
> something.  Python claimed to be a "minimalist" language.  When I switched
> from Perl to Python, it really felt like a breeze, because everything was
> in order.  Therefore, when I switched from Python to Ruby, I felt it was
> like a step backward in this regard.  I don't mind that a language
> provides many constructs/methods as long as each one has different purpose
> and/or has different performance.  Otherwise, I think it will become more
> burden to the programmer.  Does anybody know why Ruby didn't aim to be a
> "minimalist" language?

Ruby strikes a good balance between minimalism and maximalism.  You need *some*
flexibility.

> (For example, both "if" and "unless" are given instead of just "if"; I
> haved used both regularly, but still I cannot avoid having "!" from time
> to time, in which case probably then only "if" is sufficient.  Also both
> "!" and "not" are given, and further they have different precedence; I
> think even in Perl they are just synonymous; I think it is probably better
> to simply use parentheses whenever precedence is in doubt instead of
> relying on the precedence table, just like many programming books say.)

"unless" is manna from heaven.  "if not" is such a contortion.  Positive logic
is clearer than negative logic.  In C-related languages, I would code the
if/else in such a way as to avoid "not".

So what on earth is wrong with "unless"?  It's a perfectly normal English word
given a perfectly good use in Perl/Ruby.

The point about precedence is well made.  For a language that follows POLS,
there certainly seem to be some tricky (and arbitrary) precedence issues, and I
don't know them.  Thankfully, they haven't surprised me yet.

One point you should have mentioned was aliases.  I don't know how many people
in the group like them.  Personally, I like them in the built-in classes,
because it accomodates different language backgrounds.  I prefer "map" and
"indices"; were it not for aliases, I'd probably have to conform to "collect"
(what the hell does *that* mean? ;) and "indexes" (a bastard of a word if ever
I saw one).

The point is, however, that everyone *knows* about the "built-in" aliases; in
users' classes, domain-specific functionality should guide the choice of method
names reasonably clearly.

> Regards,
>
> Bill

--Gavin (sorry to respond so verbosely to a point you didn't even make :)