What are your favorite Ruby features?

ruby-talk
41

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

···

2009/2/18 Juan Zanos <juan_zanos@talkhouse.com>:

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.

42

Hi --

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

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.

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

···

On Wed, 18 Feb 2009, Juan Zanos wrote:

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

On Wed, Feb 18, 2009 at 2:38 PM, Rick DeNatale <rick.denatale@gmail.com> >> wrote:

On Tue, Feb 17, 2009 at 2:40 PM, David Masover <ninja@slaphack.com> wrote:

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

43

Florian Gilcher wrote:

David Masover wrote:
Same here. I think of them as FGPs: Feel-good parentheses, used because they make people accustomed to C or Java feel more comfortable, though they do not contribute any real code value.

Thats a harsh statement for those that do actually like parantheses and 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:

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.

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.

···

On Feb 17, 2009, at 9:30 PM, James Britt wrote:

--
James Britt

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

44

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

45

That's interesting, I see it the other way round: because we have underscores as clear separators between parts of an identifier we can use short names (e.g. #to_s as compared to Java's toString(), #to_a etc.).

Having said that I do not really care much and follow the rule you posted: just blend with whatever convention is present in the language of choice. Readability - especially for others - is more important than feelings about ugliness. In a project with at least two developers you can be pretty sure that whatever convention you choose it will hurt at least one of them in the eye. :slight_smile:

Kind regards

  robert

···

On 16.02.2009 18:48, Horea Raducan wrote:

In my opinion a well managed project will use whatever style convention is
predominant in the language of choice. So I am stuck with the ugly
convention. Maybe it is just me, looks like no other people complain. But it
is like a thorn in my eye and I think it reduces the expressiveness of the
language, it almost forces us to use short/non-expressive names for methods
and variables.

46

David Masover wrote:
Same here. I think of them as FGPs: Feel-good parentheses, used because
they make people accustomed to C or Java feel more comfortable, though they
do not contribute any real code value.

Thats a harsh statement for those that do actually like parantheses and not
because they are C//Java-Guys.

I did not think so, unless you feel inferior because you are a C /
Java guy, which IMHO you should not.

Nice bait. But I just had dinner.

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

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

I find the second irritating because those parens are sooo superfluous.
Does that mean that the first idiom is bad style??? Certainly not, I
can get used to it if I must.

I consider it bad style. It's a personal opinion. I can live with people using it, thats the freedom Ruby gives them.
If I hack other peoples code, I have no problem with using it to keep the code consistent.

As I said: I consider it a supreme feature of Ruby of making this optional depending on your viewpoint.

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

Very valid point of view, but my brain sees it as a declaration. My
brain could be trained to see it as a tuple, but right now I do not
want to do that.

Sure, it is a declaration, but for two seperate entities (the method and its arguments). We could go on like this for ages ;).

Actually, I think round braces are more an indicator of a secret lust for LISP.

Regards,
Florian

···

On Feb 18, 2009, at 1:04 PM, Robert Dober wrote:

On Wed, Feb 18, 2009 at 9:48 AM, Florian Gilcher > <flo@andersground.net> wrote:

On Feb 17, 2009, at 9:30 PM, James Britt wrote:

47

yes, for a def the parentheses are superfluous. However, for a method
call with more than one argument they often add quite a bit
readability, at least for me.

I also often write things like

foo(bar baz)
foo(bak, (bar baz))

I really wish it was possible to write

foo (bar baz)

but it issues a warning in ruby.

What I like about Ruby is that many things are easy to start and
change, and once written they are still short enough to grasp.

The features that make your programs short are

1) useful utility functions in the stdlib and the possibility to
monkey-patch in things that you do repeatedly

2) useful return values of many methods

Together they allow chaining of methods that makes a single line of
code do several things in a readable way.

On the other hand there are places where you hit limits.

Methods like gsub! that can return nil instead of the value on which
it operates.

Webrick is a nice simple web server included in stdlib. It's easy to
start with. It has authentication and index generation but last time I
asked around it seemed impossible to merge the two without rewriting
substantial part of webrick.

Thanks

Michal

···

2009/2/18 Robert Dober <robert.dober@gmail.com>:

On Wed, Feb 18, 2009 at 9:48 AM, Florian Gilcher <flo@andersground.net> wrote:

On Feb 17, 2009, at 9:30 PM, James Britt wrote:

David Masover wrote:
Same here. I think of them as FGPs: Feel-good parentheses, used because
they make people accustomed to C or Java feel more comfortable, though they
do not contribute any real code value.

Thats a harsh statement for those that do actually like parantheses and not
because they are C//Java-Guys.

I did not think so, unless you feel inferior because you are a C /
Java guy, which IMHO you should not.

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

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

I find the second irritating because those parens are sooo superfluous.
Does that mean that the first idiom is bad style??? Certainly not, I
can get used to it if I must.

48

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

···

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

2009/2/18 Juan Zanos <juan_zanos@talkhouse.com>:

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.

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

49

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

···

On 18 févr. 09, at 10:04, 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 Wed, 18 Feb 2009, Juan Zanos wrote:

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

On Wed, Feb 18, 2009 at 2:38 PM, Rick DeNatale >>> <rick.denatale@gmail.com> wrote:

On Tue, Feb 17, 2009 at 2:40 PM, David Masover >>>> <ninja@slaphack.com> 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?).

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.

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.

50

Florian Gilcher wrote:

David Masover wrote:
Same here. I think of them as FGPs: Feel-good parentheses, used because they make people accustomed to C or Java feel more comfortable, though they do not contribute any real code value.

Thats a harsh statement for those that do actually like parantheses and not because they are C//Java-Guys.

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:

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.

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.

Except you can't do this:

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:

···

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

On Feb 17, 2009, at 9:30 PM, James Britt wrote:

===
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 Gilcher

--
Florian Gilcher

smtp: flo@andersground.net
jabber: Skade@jabber.ccc.de
gpg: 533148E2

51

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

52

Hi --

Florian Gilcher wrote:

David Masover wrote:
Same here. I think of them as FGPs: Feel-good parentheses, used because they make people accustomed to C or Java feel more comfortable, though they do not contribute any real code value.

Thats a harsh statement for those that do actually like parantheses and 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:

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

···

On Thu, 19 Feb 2009, James Britt wrote:

On Feb 17, 2009, at 9:30 PM, James Britt wrote:

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

53

Oh but I like LISP too, you see there is always some common ground :wink:
Actually I believe that my relative dislike for parens comes from Smalltalk....
Robert

···

On Wed, Feb 18, 2009 at 1:47 PM, Florian Gilcher <flo@andersground.net> wrote:

Actually, I think round braces are more an indicator of a secret lust for
LISP.

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

54

Hi --

···

On Wed, 18 Feb 2009, Florian Gilcher wrote:

Actually, I think round braces are more an indicator of a secret lust for LISP.

I've never written any Ruby code for the purpose of making C and Java
programmers feel comfortable, and I don't secretly lust for Lisp. I
think that takes care of all the non-Ruby motives attributed to those
of us who wrap parameter lists and (some) arguments in parentheses :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

55

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

···

2009/2/18 Juan Zanos <juan_zanos@talkhouse.com>:

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

2009/2/18 Juan Zanos <juan_zanos@talkhouse.com>:

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.

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

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?

56

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

···

On Wed, Feb 18, 2009 at 4:08 PM, Juan Zanos <juan_zanos@talkhouse.com> wrote:

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?

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

57

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

···

--
James Britt

58

Hi --

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

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

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.

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.

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.

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

···

On Thu, 19 Feb 2009, Juan Zanos wrote:

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

On Wed, 18 Feb 2009, Juan Zanos wrote:

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

On Wed, Feb 18, 2009 at 2:38 PM, Rick DeNatale <rick.denatale@gmail.com> >>>> wrote:

On Tue, Feb 17, 2009 at 2:40 PM, David Masover <ninja@slaphack.com> >>>>> wrote:

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

59

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

···

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.

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

60

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.

Example from earlier post:

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

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

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

Regards,

Bill

···

From: "James Britt" <james.britt@gmail.com>
2009/2/18 Robert Dober <robert.dober@gmail.com>:

On Wed, Feb 18, 2009 at 9:48 AM, Florian Gilcher <flo@andersground.net> wrote: