> It gets ambiguous if div takes more than one argument
> y =3D 1.div 2.div 3 , 4
>
> Does 4 go to 1.div or to 2.div?
>
> I would write them like this, though as was pointed out, TIMTOWTDI
> 1.div(2.div 3) # one arg
> 1.div 2.div(3) , 4 # two args to 1.div
> 1.div(2.div 3 , 4) # two args to 2.div
>
> > 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:
>
> > =A0 =A0val y =3D 10 div (10 div 5)
>
> Seriously? But that looks messy. It's hard to tell what is the method, wh=
at
> is the variable, and how the code is formed at a glance. If 10 were store=
d
> in a variable, it would look like div was an argument, not a method.
>
> Yeah, I'm kidding. The point is you say those things about Ruby, because =
you
> are used to Scala. But coming from Ruby, you'd say those things about Sca=
la.

Yeah, in Scala you cannot have 2 arguments if you don't put a . and ()
in the method call. So your ambiguous examples are not valid in Scala.
They did this because they fully expect you to use the parenthesis
most of the time as a convention, and I have to say, I praise them for
this.

In Scala, you have the option, just like Ruby, but there is a clear
sense of when and when not to use it. It's not really arbitrary when
working with Scala code. I usually find myself just knowing when it's
best to drop the . and () and when to include it. I have no such
guideline really with Ruby, as a lot of code seems to make this choice
arbitrary. For the time being as I learn, I'm just using parenthesis
to avoid confusion.

Oh, your ruby example is valid syntax? I will try it. There's no way I
would even conceive of writing code like that. I hope others don't
either.