[ruby-talk:19211] 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.

[snip]

> 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 don't like having { .. } either, I think I would prefer to see just do ..end.
Especially since I can can see no use in having two syntaxes for the same thing
that differ only in precedence. This has come up many times before and so I
think they are both here to stay.

> 4) To replace a single backslash with two, you need to write gsub(/\\/,
> '\\\\\\\\')!! Ouch!

True but does it really come up often enough to worry about??

> 5) It is too bad that the book says that you should use the notation
> obj.method and advise instead using the obj.method().. It was a very
> good point of Eiffel, apparently the usage of obj.method can lead to
> problems in some cases, maybe these problems are caused by the "dynamic"
> nature of Ruby and can't be avoided, it would be nice if they could be
> solved though.

It's because without the brackets the { .. } would bind to the last argument to
a function instead of to the function as would generally be intended. It's
purely a matter of personal preference though it is safer to always use
brackets. I generally use brackets except on print statements and functions with
no arguments.

> 8) Between
> 	[ 1, 2, 3, 5 ].each {|val| print val, " " }
> and
> 	foreach val in ([ 1, 2, 3, 5 ]) {print val, " " }
> I find that the second is much more intuitive: It reads nearly as en
> English sentence.
> The first one is "pushed" quite heavily in the book, but isn't very
> readable IMHO.

I agree but I have never been able to get foreach to work in my scripts. They
always fail with parse errors. Is it really allowed in ruby?? I would much
prefer foreach to for since it "reads" better.

> 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.

I think I like it the way it is.

> 11) I prefer elif instead of elsif ;-)

You get used to it. I like this the way it is too :)

> 12) I like very well the way array index are used but I do not find the
> meaning of a[5,2] as a[5..6] very natural. The way FORTRAN does it
> a[5:2] is better IMHO.
> It may cause a conflict with the "? :" operator, though.

I don't like the a[x,y] notation either. I would rather they returned the
values at those postions and in that order. So a[5,2] would return an array with
element 5 and 2 of the first array as first and second elements of the new
array. I don't know if it'll cause a problem with ?: though. Matz, please :)

> 13) About the ranges: I like having "closed" and "semi-open" ranges, but
> I find that .. and ... are too easy to mistake one for the other.
> Something closer to the mathematical notation would be nice.

... is another thing I don't like( gee I seem to not like alot, don't I?? :).
But I have never had any trouble telling the two apart. Also I usually only use
.. .

> 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.

It's just a different convention one with I have no trouble with at all, though
maybe it might be nice to be more consistent with c in this respect.

> 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).

I don't like the word versions of those operators and, of course, I never use
them :). I do believe ruby has both versions of operators. I *think* they are |
and &.

> 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.

Not familiar with eiffel so I can't say.

> 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.

I don't find this confusing at all. Besides #{ .. } looks better :).

> 20) Reading a line in a file: Why gets or getlines return the line with
> the end-of-line?
> 99% of the time, the first action will be chop! or chomp! to get rid of
> the end-of-line, and it has to be done carefully in order to avoid
> portability problems (an end-of-line is two character on Windows or
> MacOS).
> IMHO, it would have been much better if by default:
> gets and getline return without the end-of-line and there are other
> methods which returns the line with the end-of-line: get_full_line for
> example.

You can change some variable( I can't remember just now what it is ) to do
this. My personal preference in the matter seems to be the same as yours. One
problem that I can think of is that it might hide the end-of-file. Perhaps in
addition to autochomping they could notify us when the end-of-file is reached as
well?? I don't think we need non-chomping versions. Just flip the variable I
mentioned previously. Only now it would make the gets's not chomp instead of the
way it is now.

> So here it is, I hope that maybe some points can be interesting.
> Have a nice day.

Thanks for posting. I am sure this will stir up a debate.

Sincerly,
Chris Moline