
Scala Actors are Just Code - No Magic - LiveTheDream
http://dearjunior.blogspot.com/2011/08/scala-actors-are-just-code-no-magic.html?m=1
======
catch23
I think languages that allow the use of non-alphanumeric characters as method
definitions make the language appear more magical simply because it looks like
built-in language syntax. I remember when I first looked at sbt, they were
creating directory paths with the '/' as an operator to concatenate strings.
(ie "home" / "user") I'm guessing that might also be the reason Ruby is cited
as magical all the time.

~~~
cmelbye
I really can't stand this trend. When I took a look at Lift, it was riddled
with these "magical" method definitions that look nice but mean absolutely
nothing to someone who's new to the framework. I'll gladly take a self-
explanatory alphanumeric method name over a "/", a "+", etc.

~~~
barkmadley
Why not have both? Also do you happen to use any regular expressions ever? Can
you imagine specifying a regular expression using self-explanatory
alphanumeric method names?

------
kenbot
Regarding the for loop, it's not magic either. "For comprehensions" in Scala
are a wonderful syntax sugar that can look like familiar "for loops" for Java
folk, or familiar "do loops" for Haskell folk depending on how you use them.
But they always desugar to flatMap/map/withFilter method calls that you could
have written yourself -- there is nothing "special" about them in that regard.

~~~
barkmadley
The desugaring process is what makes the for loop magic. I cannot write a
different control structure that looks like the that for loop in scala without
touching the compiler.

A counter example that shows how to avoid the sugar would be "if expressions"
in smalltalk (simplified, may differ to reality). In smalltalk, the abstract
boolean class has a method 'if'. And the "true" subclass of the boolean class
implements the 'if' method to execute its first parameter, while the "false"
subclass implements the 'if' method to execute its second parameter.

