[ruby-talk:19202] Re: Some remarks from a nembie in Ruby

On Mon, Aug 06, 2001 at 05:24:47PM +0900, Renaud HEBERT wrote:
> After having read the book "Programming Ruby: The Pragmatic Programmer's
> Guide" with an open mind (I hope), I took some notes about what I
> like/dislike about the Ruby language.

Thanks for a very nice post. I think a discussion like this is really
useful.

> 1) Ruby's syntax seems a little complicated, it must give nightmares to
> those who code text editors with color highlighting :-). It has many
> different types of blocks delimiters: do .. end, { .. }. 
> This added complexity has no obvious advantage in readability IMHO, and
> is bad for vi as the "%" command only works with simple delimiters.

I think the complicated syntax is the price you pay for convenient typing.
(For example the ability to call methods both with and without paranthesis.)
I guess this depends on your mindset. I prefer a slightly "purer" syntax
than Ruby's, but in real life it almost never causes any problems for me
(I occasionally write { ... end.)

> 3) Minor nitpicking: The operator === isn't commutative that is to say A===B
> isn't equivalent to B===A.  I find it bothersome, because "visually" it looks
> like a "superset" of ==.  Maybe naming the operator "in?" or "contain?" would
> have been better IMHO...

I agree, perhaps it shouldn't even be an operator. I never use it in my
own code, only implicitly in case expressions.

case_of? is probably the best name.

> 6) I like the multiple affectation very much! But by default it drops
> silently non-affected values, I find this quite dangerous.
> I would prefer the following usage:
> a,b = 1,2,3 --> Warning (or maybe error?).
> a,b,.. = 1,2,3 --> dropping silently the 3. (The ",.." is just an
> example here.)

Agreed. Warning or error should be given at compile time.

> 7) I find the following discrepancy quite annoying/dangerous:
> 	print "toto" while false; # --> doesn't output anything
> whereas
> 	begin
> 	  print "toto"
> 	end while false; --> outputs "toto"	

It is not that consistent, but it feels very natural to me. I'm not sure why.
Also note that while-loops are much more common than do...while-loops,
especially for short loops like this one, so it is much more convenient to have
a one-line while-loop than a one-line do-while-loop in the language.

> 9) Another construct that could be improved IMHO: 0.step(12,3) ...

Agreed, it's one of those things that you always have to look at a bit to
realize how it steps.

A more readable way would be to loop by example, for example like
this:

# Loops through 1,2,3,4,5,6,7
[1,nil,7].step

# Loops through 0,3,6,9,12
[0, 3, nil, 12].step ...

# Loops through 2,4,6,8,10,12,...,24
[2, 4, 6, nil, 24].step

# Raises exception
[0, 5, 10, nil, 17].step

Perhaps it should also recognize geometric progression, I'm not sure.
(Geometric progression would require at least three examples, otherwise
it would default to arithmetic progression.)

Perhaps this should be an RCR.

> 10) I'm wondering why Ruby  use the brain dead C/Unix convention that
> 010 == 8 ?
> A much better construct would be 0o10 for octal and 010 == 10.  Maybe to
> avoid mistakes, a warning could be printed when there is a number which
> starts with a 0, this warning could be easily disabled of course.

Agree that this is braindead. Most people will be very surprised that
x = 010
gives x the value 8.

> 14) The 0 and "" are evaluated as true !!  I'm not sure if it has any
> benefits but IMHO it must be quite easy to make a mistake..  It would be much
> better to either :
> 	* evaluate them as false
> 	* not evaluate them as boolean at all.

I actually see this as a feature. It allows you to use nil to signal an
error/special condition without mixing it up with 0 or "". Thus in ruby it is
OK to write

	while (getword())
		..

While in Perl you would have to write (Perl syntax rusty, please excuse)

	while (defined(getword())
		..

Of course, 90% of the people forget about that 90 % of the time and just write

	while (getword())
		..

And when someone enters a blank word "" the code blows up. That 0 and ""
are seen as false is, I think, a pollution from other langauges. A pure rubyist
would not see this as a problem.

> 15) I don't see the need for "&&" and "and" only for precedence reason..
> I think that when expressions get complicated, one should use
> parenthesis, otherwise it is just asking for troubles..
> On the other hand, there may be a need for both "short-cut" and
> "non-shortcut" logical operators (ADA has both).

"and" is not intended for logical expressions. That would be entirely 
unreadable. The reason that it is in the language is that you want to
write things as

	f = File.open(...) or puts 'error'

rather than

	(f = File.open(...)) || puts 'error'

So you can see "or" as || for expressions. 

> 16) If I understand well, mix-in are used to do the same thing as the
> multiple inheritance, why not use the same multiple inheritance scheme as
> Eiffel ? It seems simpler to me.

I'm not sure how Eiffel does multiple inheritance. How does it deal with the
problems of name collisions and cycles in the inheritance graph?

> 17) the "automatic" declaration of local variables may be dangerous,
> does the equivalent of Perl "use strict" exist? Same question with the
> equivalent of "perl -w".

In Perl, if you forget to declare a local variable you get a global variable.
Also in Perl, you can do lots of things to undefined variables, such as "$i +=
1". In Ruby you get warnings.  Because Ruby is less dangerous, "use strict" is
not really needed.  Ruby does not have any way of declaring variables, so it is
unclear how something similar to "use strict" would work. 

For example, look at the following

	niklas = 1
	niklas += 1
	puts niklas

If you misspell the first niklas you get an error on line 2 because niklas is
nil. If you misspell the second niklas you get an error on line 2, because
your misspell is nil. If you misspell the third niklas you get an error on that
line. So it is not so easy to bite yourself in the foot.

Ruby has "ruby -w" but I'm not sure what it warns about.

> 19) I would have preferred "%{variable}" instead of "#{variable}", as %
> is already "special" for strings..
> This way, the meaning of # would be simpler: It would only be used for
> commentaries.

Perhaps. OTOH, there is an RCR that suggests that #i should insert the
variable i. If we do this, we cannot use % because it would conflict
with %i.

% and # are used for different things. Perhaps it is good that they
are different.

> 21) The readability of "here documents" isn't very good. Instead of
> aString = <<END_OF_STRING
>    text
> END_OF_STRING
> something like
> aString = <<DELIM
>     text
> DELIM>>
> may be easier to read IMHO.

I agree that it looks nicer. Another thing I would *really* like is to have
<<- strip the indentation of the current source line from the here document.
For example:

		s = <<-HERE_DOC
			How do you do
^^^^^^^^^^^^^^^^########
This is         This remains
stripped

But perhaps that requires the parser to jump through hoops.

// Niklas