From: egervari <ken.egervari@...>
Date: 2010-10-11T17:55:18+09:00
Subject: Re: Why does a lot of code not include parenthesis?

On Oct 11, 2:21 am, Phillip Gawlowski <cmdjackr...@googlemail.com>
wrote:
> On Mon, Oct 11, 2010 at 6:04 AM, egervari <ken.egerv...@gmail.com> wrote:
> > In the case of the sqrt line, those parenthesis are not required, and
> > you're right - they are less readable.
>
> > But take for example this line:
>
> >    y = 10.div 10.div 5
>
> > This is valid code. It produces the result "5". To me, this looks
> > really bad though. Believe it or not, I can infer exactly what it's
> > doing much easier by writing it this way:
>
> >    y = 10.div(10.div(5))
>
> > The order is very clear.
>
> And the Ruby parser should actually warn you about the ambiguity. The
> key to understanding when and why Rubyists (usually) use or not use
> parentheses is knowing that they are dropped when they are *optional*,
> and when it is, well, to taste.
>
> Same thing with block syntax. Whether to chose do...end or {...} is a
> matter of taste, and what feels "right" in the circumstances.
>
> > See, in Scala, you don't need the "." when you drop the parenthesis,
> > so dropping them both turns out to be much nicer and clearer:
>
> >    val y = 10 div (10 div 5)
>
> This isn't clear to me. Is div called on the 10, or the 5 (or on the
> 10 and the result of 10 div 5)? The result would be different. But I'm
> pretty sure that you now consider me a particular brand of
> unenlightened. But that is because I'm not familiar with Scala, nor on
> what the Scala community settled on as best practices for writing
> code.
>
> > To me, that actually looks very nice indeed (let's assume div is also
> > a method on Int in Scala). Of course, dropping all the parenthesis
> > would change the result to .2 (or 0 I guess).
>
> > I just think this mandatory "." without the parenthesis looks weird
> > and is unintuitive. I think it's better to drop both, or to have both.
> > The middle-of-the-road syntax that includes the "." just looks bad.
>
> That's more a matter of being used to it, than it being "bad" or
> "good". object.method makes it obvious that you are calling the
> #method
> on the Object, and anything that follows is a parameter you pass into #method.
>
> > Of course, once one gets used to it, I guess it'll become readable.
>
> Absolutely. A seasoned Perl vet will consider Perl code very readable,
> too, after all. ;)
>
> > Just not the most intuitive, that's all.
>
> This has more to do with where you came from (IIRC, the object.method
> notation is being used pretty much everywhere, from .NET, to Java, to
> Ruby), and what you are used to, than actual intuitiveness.
>
> Of course, nobody can tell you not to use parentheses when you want
> to, and to use {...} when you want to, or to create a DSL for yourself
> where you can use "10 div 5" as valid syntax in Ruby. :)
>
> --
> Phillip Gawlowski
>
> Though the folk I have met,
> (Ah, how soon!) they forget
> When I've moved on to some other place,
> There may be one or two,
> When I've played and passed through,
> Who'll remember my song or my face.

In scala, there is no difference between operators and methods. They
are all methods. So a "/" can be a method name just like "div".
Because of this, scala lets you write statements as if they were
operators:

   Console println "Hey"

This is as valid in Scala as...

   1 + 3

So "println" is the operator basically, or is considered the method.
It's actually both.

Another way to write the addition statement in Scala is

   1.+(3)

This is the same. Because of this flexibility, it's actually much more
consistent and easily understood. You don't have to know how methods
and operators are different from each other, nor do you have to stop
and consider the precedence or the order for most cases. Scala uses a
precedence chart that is very familiar with other programming
languages and mathematics, so in Scala, it's really obvious what this
line would do:

    y = 10 / 10 / 5

This would result in .2 (or 0 I guess) while...

    y = 10 / (10 / 5)

... would result in 5. I say it's intuitive because you don't have to
resort to documentation to see how it works. It works like you would
expect it to work, and I think that's good design.

I am getting used to seeing this notation a little more, but I find
myself using parenthesis anyway much of the time, especially when a
method has multiple parameters. To me, seeing this "comma" in the
middle of nowhere is a little strange. I find myself having to
mentally put the parenthesis there, and then I ask myself, why not
just type them in :/