On 18 f=E9vr. 09, at 09:07, Robert Dober wrote:

> On Wed, Feb 18, 2009 at 2:38 PM, Rick DeNatale =20
> <rick.denatale / gmail.com> wrote:
>> On Tue, Feb 17, 2009 at 2:40 PM, David Masover =20
>> <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?).
>
> Cheers
> Robert
>
>
> --=20
> 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 =20
have some effect.

In this case the parenthesis don't make anything inherently more =20
readable and aren't helpful in resolving the nonsense names.  The =20
parenthesis are only meaningful if you already know what they mean.  =20
Readability arguments are often tainted by experience with previous =20
languages.   And it must be remembered that no programmer is born =20
knowing a previous programming language.  If we insist, implicitly or =20=

otherwise, that readability means that something looks like 'C' or =20
Java or any other language then we place limits on how much we can =20
simplify syntax.  I'd actually say that each example with parenthesis =20=

requires a lot more explanation of why they are their, what they =20
mean, what are the syntax rules that govern them, etc.

Cheers,
Juan=