--1926193751-855310258-1234969478	565
Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-855310258-1234969478=:9565"

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

--1926193751-855310258-1234969478	565
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT

Hi --

On Wed, 18 Feb 2009, Juan Zanos wrote:

>
> On 18 fr. 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.

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

Ruby Training Atlanta! April 1-3, http://www.entp.com/training/atlanta09
--1926193751-855310258-1234969478	565--
--1926193751-855310258-1234969478	565--