What are your favorite Ruby features?

ruby-talk
61

Hi --

···

On Thu, 19 Feb 2009, Robert Dober wrote:

On Wed, Feb 18, 2009 at 8:52 PM, David A. Black <dblack@rubypal.com> 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 (http://manning.com/black2\)

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

62

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

···

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

On Wed, Feb 18, 2009 at 8:52 PM, David A. Black > <dblack@rubypal.com> 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
--
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)

63

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 doubt you'll get much disagreement that operator precedence rules for c (or Ruby) are complex enough that there are cases where the use of parentheses simplifies reading. That doesn't seem to be something anyone is questioning.

Cheers,
Juan

···

On 18 févr. 09, at 18:43, Bill Kelly wrote:

From: "James Britt" <james.britt@gmail.com>

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.

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.

64

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.

...

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.

Somehow this reminds me of the old story of a waiter motioned over to one of
his tables, the customer said:

"Would you taste this soup?"

Waiter, "I'm sorry sir, if there's something wrong with your soup, I'd be
happy to have the chef fix it or bring you something else, but the health
inspector is rumored to be paying a surprise visit, and we've been warned
not to do anything which might cause a problem."

Customer, "No, I insist, please taste my soup!"

The waiter looked around to see if anyone was looking, turned back to the
customer, and said,

"Okay, where's your spoon?"

To which the customer replied

"AHA!"

···

On Wed, Feb 18, 2009 at 6:43 PM, Bill Kelly <billk@cts.com> wrote:

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

65

Hi --

···

On Thu, 19 Feb 2009, Juan Zanos wrote:

On 18 févr. 09, at 18:43, Bill Kelly wrote:

From: "James Britt" <james.britt@gmail.com>

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.

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.

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 (http://manning.com/black2\)

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

66

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.

Again:

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

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 find these reasons sufficient and non-arbitrary.

I doubt you'll get much disagreement that operator precedence rules for c (or Ruby) are complex enough that there are cases where the use of parentheses simplifies reading. That doesn't seem to be something anyone is questioning.

But we do get disagreement among programmers as to the *degree*
to which parens ought to be used to clarify operator precedence.

The same kind of disagreement happens in C with regard to whether and when to use braces when the body of a conditional
is a single statement.

  if (foo)
    bar();
  else
    baz();

  if (foo) {
    bar();
  }
  else {
    baz();
  }

  if (xyzzy)
    if (foo)
      bar();
    else
      baz();

  if (xyzzy) {
    if (foo)
      bar();
    else
      baz();
  }

···

From: "Juan Zanos" <juan_zanos@talkhouse.com>

67

[Sorry, hit some control key and sent my previous message before
completing it.]

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.

Again:

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

"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 find these reasons sufficient and non-arbitrary.

I doubt you'll get much disagreement that operator precedence rules for c (or Ruby) are complex enough that there are cases where the use of parentheses simplifies reading. That doesn't seem to be something anyone is questioning.

But we do get disagreement among programmers as to the *degree*
to which parens ought to be used to clarify operator precedence.

The same kind of disagreement happens in C with regard to whether and when to use braces when the body of a conditional
is a single statement.

  if (foo)
    bar();
  else
    baz();

  if (foo) {
    bar();
  }
  else {
    baz();
  }

  if (xyzzy)
    if (foo)
      bar();
    else
      baz();

  if (xyzzy) {
    if (foo)
      bar();
    else
      baz();
  }

  if (xyzzy) {
    if (foo) {
      bar();
    }
    else {
      baz();
    }
  }

Some programmers argue for one extreme or the other, while others
take some middle ground.

And some change their minds over the years, maybe multiple times.

*shrug*

Here's some more ruby:

http://codefluency.com/articles/2008/08/17/arrow-lambdas-a-ruby-1-9-vignette/

The following is a completely legal _single_ lambda being immediately invoked

-> a = 1, b = 2, c, &d ; e { e = d.(a * b * c); e + 1 }.(3) { |p| p * 4 }

...and with parens:

-> (a = 1, b = 2, c, &d ; e) { e = d.(a * b * c); e + 1 }.(3) { |p| p * 4 }

They're both funky, but the latter is clearer to me.

Anyway, really I don't think it matters whether it's function declarations, operator precedence, or (in the case of the C example) where to add braces...

Seems we just have individual programmers, with their own sense
of style, each (hopefully) trying to make their code as readable
as possible.

De gustibus, and all that....

Regards,

Bill

···

From: "Juan Zanos" <juan_zanos@talkhouse.com>

68

I haven't heard any different practices with regard to parenthesis and operator precedence in this discussion. Am I wrong about this? And with regard to operator precedence it doesn't sound like there are any unique issues with Ruby. Well, other than the fact that you can create new operators with Ruby and you can't in most languages. But nobody has mentioned that feature.

Cheers,
Juan

···

On 19 févr. 09, at 10:21, David A. Black wrote:

  This message is in MIME format. The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
Hi --

On Thu, 19 Feb 2009, Juan Zanos wrote:

On 18 févr. 09, at 18:43, Bill Kelly wrote:

From: "James Britt" <james.britt@gmail.com>

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.

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.

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 (http://manning.com/black2\)

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

69

Hi --

···

On Fri, 20 Feb 2009, Juan Zanos wrote:

On 19 févr. 09, at 10:21, David A. Black wrote:

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

I haven't heard any different practices with regard to parenthesis and operator precedence in this discussion. Am I wrong about this? And with regard to operator precedence it doesn't sound like there are any unique issues with Ruby. Well, other than the fact that you can create new operators with Ruby and you can't in most languages. But nobody has mentioned that feature.

I probably misunderstood you. Anyway, I'm pretty parenthesesed out :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 (http://manning.com/black2\)

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

70

Even after 5 years of ruby, I cannot stand ruby code where
def foo bla
omits parens at definition-time.

I have no real problem if method calls omit parens, but my eyes HATE it
if the () is omitted - my brain needs extra time to decide where it
starts and ends, especially if more arguments are used.

···

--
Posted via http://www.ruby-forum.com/.