What are your favorite Ruby features?

Ruby
41

On Wed, Feb 18, 2009 at 2:38 PM, Rick DeNatale [email protected]
wrote:

On Tue, Feb 17, 2009 at 2:40 PM, David M. [email protected] wrote:

def foo bar

That is very hard to read indeed, but why?

def foo( bar )

This is not so much better!
We are all totally accustomed to the fact that foos and bars designate
the same kind of thing.

I therefore think that

def fact n

is more readable for most people than

def n( fact )

which is nonsense of course (in the particular context).

Naming seems more important than params or not params (of course if I
might say?).

Cheers
Robert

42

2009/2/18 Juan Z. [email protected]:

limits on how much we can simplify syntax. I’d actually say that each
example with parenthesis requires a lot more explanation of why they are
their, what they mean, what are the syntax rules that govern them, etc.

Parentheses are traditionally used to group things together. If you
have things that are logically linked together but do not visually
appear so then adding parentheses which are not required might help
you to make the code more readable.

This has nothing to do with other programming languages, you should
have learned that in elementary school during your math classes.

Thanks

Michal

43

On 18 févr. 09, at 09:07, Robert D. wrote:

def foo( bar )

–
There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

Good point. Syntax isn’t all there is to readability. But it does
have some effect.

In this case the parenthesis don’t make anything inherently more
readable and aren’t helpful in resolving the nonsense names. The
parenthesis are only meaningful if you already know what they mean.
Readability arguments are often tainted by experience with previous
languages. And it must be remembered that no programmer is born
knowing a previous programming language. If we insist, implicitly or
otherwise, that readability means that something looks like ‘C’ or
Java or any other language then we place limits on how much we can
simplify syntax. I’d actually say that each example with parenthesis
requires a lot more explanation of why they are their, what they
mean, what are the syntax rules that govern them, etc.

Cheers,
Juan

44

On 18 févr. 09, at 10:00, Michal S. wrote:

only meaningful if you already know what they mean. Readability
example with parenthesis requires a lot more explanation of why
This has nothing to do with other programming languages, you should
have learned that in elementary school during your math classes.

Thanks

Michal

Michal,

Did you look at the message to which I was replying? Were
parentheses being used to group things together? No. They were
not. They were being used to distinguish a single argument from a
function name. In what elementary school should I have learned that
use of parentheses?

Cheers,
Juan

45

Hi –

On Wed, 18 Feb 2009, Juan Z. wrote:

That is very hard to read indeed, but why?

some effect.
mean, what are the syntax rules that govern them, etc.
I agree (except for your last sentence). I honestly don’t give C or
Java (or Lisp, etc.) a moment’s thought in any of this, when I’m
writing Ruby. Just Ruby.

One thing I’ve had to come to terms with, reluctantly (because it
would be so nice if it were otherwise), is that there is literally no
such thing as inherent readability. Readability simply does not inhere
in the notation, any more than it does in a given alphabet.

I’m not sure why these discussions, when they’re about Ruby, always
seem to be 99% about other languages. Ruby has one of the most
distinct visual styles ever. I guess the issues arise because you
can make it look like C:

printf(“%s\n”, string);

or Lisp (sort of), or whatever. I’ve always thought of that stuff as
marginal – kind of a party trick, more than a real exploration of
Ruby’s own style.

The reason I don’t agree with your last sentence is that I don’t think
it’s possible to explain or defend most of these things. For example,
the convention of:

attr_accessor :x

without parentheses can’t really be explained or rationalized. It’s
just the convention.

In the end, it’s a bit fuzzy. There’s a clustering around certain
conventions (like the attr_accessor one), but there are outlying
practices, slopes to the bell curve, whatever. I do wish people would
not write:

def a b, c=1

but if they do, I can’t really expect an explanation. It’s just what
they like.

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp

46

On 18 févr. 09, at 10:04, David A. Black wrote:

the same kind of thing.
does have some effect.
example with parenthesis requires a lot more explanation of why
in the notation, any more than it does in a given alphabet.
Ok. We don’t have to agree completely. We both seem to agree that
there are arbitrary aspects to syntax conventions that do not
inherently affect readability. Perhaps where we disagree is that I
do believe something can be inherently more or less readable and you
do not. I believe that overly complicated syntax becomes less
readable and even more unwritable. So I tend to prefer a simpler
syntax even if it’s slightly different from a particular convention.

Cheers,
Juan

47

2009/2/18 Juan Z. [email protected]:

only meaningful if you already know what they mean. Readability
Parentheses are traditionally used to group things together. If you

Michal,

Did you look at the message to which I was replying? Were parentheses
being used to group things together? No. They were not. They were being
used to distinguish a single argument from a function name. In what
elementary school should I have learned that use of parentheses?

I have taken your “each example with parenthesis” as referring to the
parenthesis discussion on this thread in general, not the particular
examples with defining methods.

For that the ‘def’ keyword should be distinctive enough.

Thanks

Michal

48

On Wed, Feb 18, 2009 at 4:08 PM, Juan Z. [email protected]
wrote:

Michal,

Did you look at the message to which I was replying? Were parentheses
being used to group things together? No. They were not. They were being
used to distinguish a single argument from a function name. In what
elementary school should I have learned that use of parentheses?
I agree with you here, Juan.
We are of course not talking about parentheses which are needed and
IIRC we learned in math classes to leave away all parentheses which
were not needed.
Robert

49

Florian G. wrote:

not because they are C//Java-Guys.
It’s simply an observation based on reasons people have given me when I
try to understand what value the parens offer. It ends up being, “I’m
used to them”, or, “It looks weird without them”, or, “I find it more
readable.”

Basically, their absence makes some people uneasy; they feel better with
them there, though they do not provide any information or programmatic
value.

I’m sure there are people who did not come to Ruby after using Java or C
and still think the parens make the code easier to work with. I just
haven’t met them. :slight_smile:

Except you can’t do this:

def foo (my, tuple, arg); end

Also, i tend to brace long and unbalanced statements:

===
var_foo_bar = (::Something::Somewhere::Object.new(
:foo => “bar”
)
)

There are times when the parens may make the arg list more readable,
but it ends up being a matter of taste, and that comes from exposure.

The more people add the redundant parens, the more they see it as
“right”, and the more they do it.

I prefer to omit whatever I can until I have a good reason not to.
Maybe that good reason ends up being, “I’m making more stupid errors”,
and that’s fine, but so far I’ve had fewer such errors without the
parens than with them.

I don’t expect anyone is going to change their minds on this based on
words alone, but it’s interesting to see how preferences evolve.

For example, in learning Haskell, I’ve come across a number of places
that explain that while one can use parens in various places, the
preferred style is to leave them out when possible. Different culture.

–
James B.

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff

50

On Feb 18, 2009, at 6:30 PM, James B. wrote:

or C and still think the parens make the code easier to work with.
I just haven’t met them. :slight_smile:

Meet: me. No Java//C-Exposure beyond the absolute must in university
courses (and I learned Ruby before them). And as I said before, it’s
highly depending on the context.

def foo (my, tuple, arg); end

Sure, it is not a perfect image. It’s just the direction.

There are times when the parens may make the arg list more
readable, but it ends up being a matter of taste, and that comes
from exposure.

I’m a fan of consistency. Even in relativly strict defined languages
like Java and C I always shriek when seeing people using several
styles just as they see fit. Obviously, making them mandantory (and
them omittable in some very special cases…) doesn’t fix the problem
as well.

As you said: there are moments where parens help (“def a b,c = {}”
being a good example). So, I prefer to stick to them in all parameter
lists to eliminate this question. Especially because I have a tendency
for creative use of parameter lists (that make Java guys shriek).

Rest assured, I am writing:

===
div.address “bla”, :class => bar do
#something different
end

when using Builder//Markaby (for example), because parens would
clutter the declaration.

The thing is that I try not to mix the styles. As I said, I clearly
prefer:

===
foo(bar(batz))

over

foo bar(batz) # looks unbalanced

To extend this:

===
some_method bar(batz)
some_other_method bar # oh

Suddently, the braces really hurt. While in a balanced display
(granted, it’s hard to conjure up nice examples):

===
some_method(bar(batz))
some_other_method(bar)

So, I prefer to just stick to the braces.

The more people add the redundant parens, the more they see it as
“right”, and the more they do it.

That sounds like they are utterly wrong.

I prefer to omit whatever I can until I have a good reason not to.
Maybe that good reason ends up being, “I’m making more stupid
errors”, and that’s fine, but so far I’ve had fewer such errors
without the parens than with them.

I don’t to parens errors as well… so? I think the difference is
neglectible.

I don’t expect anyone is going to change their minds on this based
on words alone, but it’s interesting to see how preferences evolve.

For example, in learning Haskell, I’ve come across a number of
places that explain that while one can use parens in various places,
the preferred style is to leave them out when possible. Different
culture.

Not only a different culture but also different facilities. Haskell is
far better in grasping things like “foo bar batz a” (oh, didn’t write
Haskell for at least 2 years… is that valid?).

At the end of the day, it is the projects maintainers call how the
code should be written.
Maybe it might be worthwhile to document those styles at a certain
place for maintainers to refer to “their” style.

And, thats why I tuned in: attributing brace styles other then Your
Enlightened One to other persons inability to find The True Way. There
is a language called Python for that ;).

Regards,
Florian G.

–
Florian G.

smtp: [email protected]
jabber: [email protected]
gpg: 533148E2

51

Florian G. wrote:

And, thats why I tuned in: attributing brace styles other then Your
Enlightened One to other persons inability to find The True Way. There
is a language called Python for that ;).

I think you’re putting words in my mouth.

I have my own preference, and have so far found arguments to the
contrary unsatisfying because they are usually based on previous use of
parens in other languages. (The most interesting suggestion I’ve
heard is to use the parens to indicate if the return value of the method
is useful or not. That is, whether a method is intended as a statement
or an expression.)

I’m truly puzzled when people get their back up at the suggestion that
their style preference is based on bias obtained from previous exposure
to other language, conscious or not. I don’t think too many people are
deliberately thinking, “I want to make this look like
[C|Java|Perl|PHP]”, but surely there is some bias based on experience.

Whether or not that makes anyone enlightened is yet another matter of
opinion and not all that interesting a topic. I’m certainly not
claiming it for myself.

The debate is not entirely academic. New features and syntax are being
added to Ruby on 1.9, and there are similar debates about the
readability of many things. It’s worth understanding why people have
such issues, and whether or not the difficulties can be overcome by
extended exposure, or whether there are intrinsic reason why something
is hard for people to visually parse.

Ruby is quite similar to other languages, and people bring assorted
expectations, and to what degree those expectations should be matched or
encouraged in Ruby as it evolves is a reasonable question.

52

Hi –

On Thu, 19 Feb 2009, Juan Z. wrote:

On 18 févr. 09, at 09:07, Robert D. wrote:

the same kind of thing.

arbitrary aspects to syntax conventions that do not inherently affect
readability. Perhaps where we disagree is that I do believe something can
be inherently more or less readable and you do not. I believe that overly
complicated syntax becomes less readable and even more unwritable. So I
tend to prefer a simpler syntax even if it’s slightly different from a
particular convention.

That just offloads the subjective judgment onto the concept of
“overly” :slight_smile:

I guess it comes down to this. If someone says they find

def m a, b, c=1

clearer or more readable than

def m(a,b,c=1)

I have no idea what they’re talking about – but I have to assume they
really do find it more readable, and that whatever is going on in
their brain when they look at the first version is similar to what
goes on in my brain when I look at the second.

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp

53

Florian G. wrote:

For example, i find the following irritating and bad style:

===
def initialize foo, bar, batz = {}, &block
#(vs.)
def initialize( foo, bar, batz = {}, &block )

I see the argument list as a tuple and I like it to resemble one.

However, tuples in Ruby can also be assigned without parens:

some_array = 1, 2, 3

I find that it’s purely a matter of style. I like to drop whatever
syntax I can, and infer the rest from the environment. However, I also
like the fact that they are optional – it means we don’t actually
have to agree, unless we’re working on the same codebase. We can both
use the same language, and you can use parens, and I can drop them.

That was my point – I like the syntax to be flexible like that.

Also, i tend to brace long and unbalanced statements:

===
var_foo_bar = (::Something::Somewhere::Object.new(
:foo => “bar”
)
)

In that case, I would tend to write it either like this:

var_foo_bar = Something::Somewhere::Object.new :foo => ‘bar’

Or, if that was really getting cumbersome, and I had to wrap it, I’d
probably do something like this:

var_foo_bar = Something::Somewhere::Object.new(
:foo => ‘bar’,
:frobinate => true,
:frobs => [1, 2, 3]
)

Again, a matter of style. In particular, I would be just as frustrated
with a language that did not allow superfluous parentheses as one that
required them.

We should never forget that the purpose of the language is to encode our
thoughts in a machine-readable and human-readable form. If some rule of
syntax gets in the way of that, the language is failing in its purpose.
If it’s possible for humans to write unreadable code (Perl’s “line
noise” problem), that is poor style on the part of the coder, not a
fault of the language.

54

Michal S. wrote:

Parentheses are traditionally used to group things together. If you
have things that are logically linked together but do not visually
appear so then adding parentheses which are not required might help
you to make the code more readable.

That is a good rule of thumb.

However, my editor has decent syntax highlighting, so in many cases,
things are grouped together by color. When they are not, or when it is
actually ambiguous, I use parentheses.

55

Hi –

On Thu, 19 Feb 2009, James B. wrote:

Thats a harsh statement for those that do actually like parantheses and not
still think the parens make the code easier to work with. I just haven’t met
them. :slight_smile:

I did learn C before Ruby, but post hoc ergo propter hoc is still a
logical fallacy :slight_smile:

I write what I think is clearest, which as we know means that some
people will also find it clearest and others won’t. I don’t have any
emotions or convictions one way or another about the characters ‘(’
and ‘)’ themselves.

I understand why you think it’s sort of mushy and non-rigorous to use
discretionary parentheses, and it probably is, but I can’t seem to
convince myself to stop being guided by criteria of (what I judge to
be) clarity. I’m just an old softy :slight_smile:

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp

56

Hi –

On Thu, 19 Feb 2009, Robert D. wrote:

On Wed, Feb 18, 2009 at 8:52 PM, David A. Black [email protected] wrote:

I have no idea what they’re talking about – but I have to assume they
really do find it more readable, and that whatever is going on in
their brain when they look at the first version is similar to what
goes on in my brain when I look at the second.
That seems quite likely to me and I even daresay that if you were
exposed to the first style for a given time T your brain would adapt.
And probably T is not even very long.
And vice versa of course.

Just to be clear: I do understand the notation that I don’t
particularly like. I just don’t particularly like it :slight_smile:

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp

57

On Wed, Feb 18, 2009 at 8:52 PM, David A. Black [email protected]
wrote:

I have no idea what they’re talking about – but I have to assume they
really do find it more readable, and that whatever is going on in
their brain when they look at the first version is similar to what
goes on in my brain when I look at the second.
That seems quite likely to me and I even daresay that if you were
exposed to the first style for a given time T your brain would adapt.
And probably T is not even very long.
And vice versa of course.
Robert

58

On 18 févr. 09, at 16:42, Robert D. wrote:

And probably T is not even very long.
And vice versa of course.
Robert

There are some people who begin the Zoo at the beginning, called
WAYIN, and walk as quickly as they can past every cage until they get
to the one called WAYOUT, but the nicest people go straight to the
animal they love the most, and stay there. ~ A.A. Milne (from
Winnie-the-Pooh)

Relative to time spent learning a language I’d say the T might as
well be zero. Mostly the arguments for using parentheses when they
aren’t necessary seem to be arguments of taste. There’s no disputing
taste, but simplicity is a powerful argument. If someone can give
me a convincing argument for why the way I do something is less
simple than the way they do something I’m very likely to change. I
find myself swayed by the argument that unnecessary use of
parentheses is more complicated. It’s more ink. It’s more
syntax. It’s more overloading of the meaning of the parentheses
character.

When it comes to pure taste I try to be ambivalent. If everyone in
the world decided it would be cool to switch parentheses around so
the ends pointed outside I don’t think I could raise a legitimate
argument against it. At least I can’t think of a convincing argument
off the top of my head and it would be mildly amusing.

Cheers,
Juan

59

From: “James B.” [email protected]

to other language, conscious or not. I don’t think too many people are
deliberately thinking, “I want to make this look like
[C|Java|Perl|PHP]”, but surely there is some bias based on experience.

I agree there is some bias based on experience, as I went through
a phase about 18 years ago as a C programmer, deliberately
memorizing the operator precedence table and taking small delight
in being able to write expressions devoid of any parens except
those strictly necessary to the parser.

Note, also, that my first language was Forth, which I programmed
in for seven years–initially as a hobbyist, then professionally–
before I learned C.

Forth doesn’t need parens for anything… ( they’re comment delims. )

However, I’m not sure my Forth experience played a role in my
temporary dalliance with extreme paren minimalism in C. At the
time, I felt memorizing the operator precedence table and making
use of that knowledge by minimizing use of parens was sort of a
natural course to take for someone intent on mastering the
language.

Eventually one of my co-workers told me he had trouble reading
my code. Initially my (private) reaction was, this guy isn’t
serious about his craft! He really ought to learn the language.

Thankfully I got past that phase eventually.

My current bias based on experience is that when reading code,
my brain does frequently prefer more parens than are strictly
necessary to the parser.

Example from earlier post:

2009/2/18 Robert D. [email protected]:

I find the second irritating because those parens are sooo
superfluous.

If I could have participated in this thread eighteen years ago I
would almost certainly have been in the superfluous==suboptimal
camp.

Nowadays, my brain finds the latter declaration with the parens,
more restful to the eye than the former.

It’s easier for me to see the structure at-a-glance in the
latter…

I realize this is necessarily very subjective. But my point is
just that the strictly minimal syntax required to satisfy the
parser is no longer an important criterion to me when I’m
writing code I want to be easy for me(*) to read.

*(((and apparently my poor co-workers)))

Regards,

Bill

60

Hi –

On Thu, 19 Feb 2009, Juan Z. wrote:

That is, whether a method is intended as a statement or an expression.)
those strictly necessary to the parser.
use of that knowledge by minimizing use of parens was sort of a
my brain does frequently prefer more parens than are strictly
necessary to the parser.

One of the things that confuses this discussion is that some people are
talking about the use of parentheses with regard to operator precedence rules
and others are discussing far more arbitrary and questionable usages such as
in declaring and calling functions. I think it’s telling that such a
seemingly minor complexity is cause for confusion.

I don’t think there’s any confusion, just (rather trivially, in the
overall scheme of things) different practices.

David

–
David A. Black / Ruby Power and Light, LLC
Ruby/Rails consulting & training: http://www.rubypal.com
Coming in 2009: The Well-Grounded Rubyist (The Well-Grounded Rubyist)

Ruby Training Atlanta! April 1-3, ruby training, atlanta, april 2009 - entp