> I like many aspects of ruby's syntax, but there are MANY aspects that I
> would change. I dont like having to use the 'end' keyword to terminate
> classes and functions for instance. I do really like ruby's block concept
> tho, and like being able to choose between { } and do end. Syntax
> aesthetics are somewhat specific to the individual. I like things a
> certain way, and I wouldn't want to deny someone else the ability to see
> it the way they want to.
I would vote for extending the end and enforce a "end class", "end
def", or "end module". This would make the syntax much more readable
and this is what is most important in the long term. I would even
forbid 'if' statements without a 'then'.
Overloading the '{' to do more things then know is IMO not really a good
idea.
I'm on the same page with you Lothar, I think it ought to be written out, if only for the sake of readability.
I would vote for extending the end and enforce a "end class", "end
def", or "end module". This would make the syntax much more readable
and this is what is most important in the long term.
Part of what makes ruby powerful is the fact that it doesnt sacrifice
power and brevity to increase readability. Ruby is downright unintuitive
in some places, with extremely rewarding consequences.
For instance, compare ruby blocks to python list comprehensions:
lst.reject {|x| not x.upcase.include? n.upcase }
vs.
[x for x in lst if n.upper in x.upper]
Ruby's looks cryptic by comparison. (I particularly dislike ruby's lack of
an 'in' operator - adding that would be a MUCH better way to increase
readability) Ruby blocks may not be as intuitive, but they DEFINITELY
stack better.
It would probably require three times as much code to do that in python,
particularly the regular expressions. Inline regular expressions
definitely dont do nice things for readability, but they are incredibly
powerful.
That code sample, btw, is part of a script I wrote to concatenate
pieces of incomplete rar files downloaded from a.b.startrek with BNR. Its
part of a script I use regularly, and I initially wrote it that way, I
didnt intentionally obfuscate it. I initially tried writing it in python
and got frustrated with the syntactic hoops I had to jump through.
Received: Sun, 13 Jun 2004 03:58:37 +0900
And lo, Ryan wrote:
Ruby's looks cryptic by comparison. (I particularly dislike ruby's lack of
an 'in' operator - adding that would be a MUCH better way to increase
readability) Ruby blocks may not be as intuitive, but they DEFINITELY
stack better.
Part of what makes ruby powerful is the fact that it doesnt sacrifice
power and brevity to increase readability. Ruby is downright unintuitive
in some places, with extremely rewarding consequences.
For instance, compare ruby blocks to python list comprehensions:
lst.reject {|x| not x.upcase.include? n.upcase }
vs.
[x for x in lst if n.upper in x.upper]
Unintuitive? It might help to avoid the double negative...
lst = %w{ foo BaR baZ foobar }
n = "bar"
# original
p lst.reject {|x| not x.upcase.include? n.upcase }
# no double negative
p lst.select {|x| x.upcase.include? n.upcase }
Received: Sun, 13 Jun 2004 03:58:37 +0900
And lo, Ryan wrote:
Ruby's looks cryptic by comparison. (I particularly dislike ruby's lack of
an 'in' operator - adding that would be a MUCH better way to increase
readability) Ruby blocks may not be as intuitive, but they DEFINITELY
stack better.
Ruby does have an 'in' operator.
--
lst = [1,2,3,4]
for i in foo
puts i
end
He knows about for/in -- he's talking about an 'in' operator
as in RCR 241 (mine), which some love and some hate.
Thanks. I had been looking for a way to avoid the double negative, and I
got frustrated because map doesnt behave the same way it does in python. I
hadnt realized the select function does that. I need to spend more time
with the docs.
Regardless, I think my intial claim holds up. The example with grep is
beautifully concise, but the meaning doesnt seem all that intuitive.
Higher learning curve, greater value - ultimately A Good Thing(tm).
-- SegPhault
···
On Sun, 13 Jun 2004 05:05:59 +0900, Joel VanderWerf wrote:
Ryan Paul wrote:
Part of what makes ruby powerful is the fact that it doesnt sacrifice
power and brevity to increase readability. Ruby is downright unintuitive
in some places, with extremely rewarding consequences.
For instance, compare ruby blocks to python list comprehensions:
lst.reject {|x| not x.upcase.include? n.upcase }
vs.
[x for x in lst if n.upper in x.upper]
Unintuitive? It might help to avoid the double negative...
lst = %w{ foo BaR baZ foobar }
n = "bar"
# original
p lst.reject {|x| not x.upcase.include? n.upcase }
# no double negative
p lst.select {|x| x.upcase.include? n.upcase }
