From: Renaud HEBERT Date: 2001-08-06T17:24:47+09:00 Subject: [ruby-talk:19192] Some remarks from a nembie in Ruby 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. I translated in English the notes on the things that I dislike, and I submit here these notes hopping than it can generate some interesting discussion (no flame war please). Don't feel that I'm criticizing the language, I like it very much but I thought that the things that "shocked me" could engender useful discussion/thoughts. 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. 2) When you create an object, you use the new method which call the constructor method called initialize. Why the constructor is not simply named new ? 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... OTOH, = is not commutative so... 4) To replace a single backslash with two, you need to write gsub(/\\/, '\\\\\\\\')!! Ouch! 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. 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.) 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" 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. 9) Another construct that could be improved IMHO: 0.step(12,3) ... 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. 11) I prefer elif instead of elsif ;-) 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. 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. 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. 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). 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. 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". 18) The command-line arguments of ruby are quite weird IMHO. 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. 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. 21) The readability of "here documents" isn't very good. Instead of aString = <> may be easier to read IMHO. So here it is, I hope that maybe some points can be interesting. Have a nice day. -- Renaud Hebert mailto:renaud.hebert@alcatel.fr