[#1816] Ruby 1.5.3 under Tru64 (Alpha)? — Clemens Hintze <clemens.hintze@...>

Hi all,

17 messages 2000/03/14

[#1989] English Ruby/Gtk Tutorial? — schneik@...

18 messages 2000/03/17

[#2241] setter() for local variables — ts <decoux@...>

18 messages 2000/03/29

[ruby-talk:02205] Re: parse bug in 1.5

From: mrilu <mrilu@...>
Date: 2000-03-28 02:50:30 UTC
List: ruby-talk #2205
> (I would also vote for doing away with optional parens, although this may
> be unpopular with many people or it may cause backwards compatibility
> problems. I prefer this option on the principle of least surprise grounds.)

I have to say I don't agree. Principle of least surprise goes well along
if you just use parentheses all the time. I agree though that this point
should be made really clear for beginners, much better than it has been
done so far. Maybe this is not clear because Ruby hasn't had
enough beginner mass to make endless questions of same things. At some
point FAQ will be in ten parts and the first thing in the FAQ will be
famous proverbs from Ruby Veterans and Heroes like "Use parentheses unless
you know what you do, and use them even then."

*You take risks when you don't parenthesize everything and be specific*.
You have right to be concise, but you have the responsibility for behaving
and doing it right. Usually being concise enhances readibility and
there is less rows for bugs to lurk, while that lack of space drives those
parasites to be even clever.

Doing short code right isn't easy. If Ruby executes your code in proper
manner, there's still plenty of other coders who might fall into your
trap. Ruby guesses well, I think. And usually when I'm running into
problems, that's good sign my code is too complicated. 

I think denying There Is More Than One Way To Do It is not one of Ruby's
desing goals. I hope it's quite much the opposite. Optional parentheses
live on the TIMTOWTDI side. 

TIMTOWTDI is nice because it allows one to be as pedantic, clean or  
specific as syntax allows.

I would guess it's Ruby's right to be right and the judge if some sample
of coders could not totally agree (without dispute) what some piece of
code should do. But that kind of event would show the code has too
much ambiguity and it should be clearly removed for other coders and for
Ruby by using parentheses (or whatever is appropriate).

> > For me at least, ruby's syntax is hovering near the edge of "too
> complicated".
> > Please don't push it over :)
> 
> For me too, at least in this area. I think this is where Larry ran into the
>  design Wall.

Well, I can't agree here either. I don't have any experience on the
internals of the language, but the BNF doesn't seem to be too long.
And at least Ruby has well defined syntax. Let's remember that it's not
possible to generate BNF for Perl (or maybe it is, it's just not
convenient).

> I think Ruby syntax should strive to be "intuitively obvious" in the sense
> that it is doesn't readily invite mistakes and misinterpretation--even if
> that means having to write a few more characters.

I agree. And for me it's totally intuitively obvious that everything works
with parentheses. Without them I still hardly drive into problems.

Actually I like to note that *I'm using function* here(). With perl it was
important sometimes.

In This Thread