
Martin Odersky on the Future of Scala - fogus
http://www.infoq.com/interviews/martin-odersky-scala-future
======
unoti
They talk in this article about the complexity of Scala. Odersky typically
combats that accusation by saying that Scala's not so complicated. He did that
in this article, and I've seen him and others do the same in other places.

But the fact is, it's pretty damn complicated. At least it was, to me, but I
realize now that's just because I didn't grok functional programming in the
slightest. Scala seriously turned me off at first, and I found it very hard to
learn. There's a lot of little tricks it does, and special rules. Like how
there are many different ways do progressively shorten inline function
definitions. For example: you can either say: "args.foreach(arg =>
println(arg))", or you can say "args.foreach((arg:String) => println(arg))",
or you can just say "args.foreach(println)". And the books I have explain that
in kind of a complicated way that explains partial functions way sooner than I
was ready to understand. All those different options of ways to do things made
me have a hard time understanding what the "right" way to do things was.
Similarly, the ability to do ultra-shortcuts on inline function definitions
really confused me at first, for example being able to say map(_ + _) instead
of (a,b => a + b).

For loops were also kind of bizarre to me. I remember thinking, "Jeez, would
it kill you to just let me write a frickin loop for goodness sake?"

I perceived all this as excessive trickery and complexity in the language, and
decided to bite the bullet and learn Erlang, instead. Erlang is a far, far
easier language to learn. It was a breeze, actually, once I relaxed and forced
myself to embrace it instead of hate it. (I failed to do so on a previous
attempt to learn it.) In the process, something amazing happened: I started
wishing that I had access to a lot of those things that I initially hated so
much about Scala. I started wishing that I could write map(_ + _) instead of
writing map(fun(A,B) => A + B end, L) like Erlang was forcing me to do.

Point is, if you're finding Scala off-putting or overly complex, like I did,
then consider taking the time to learn functional programming with Erlang. You
may even decide you like Erlang better. Erlang is better for some kinds of
applications and situations. But for me, I found it way easier to learn Erlang
first. Because until I was _forced_ to do pure functional programming, I
didn't appreciate the value of it. It prepared me to really appreciate Scala.

------
unoti
Wow, he saved this for the last paragraph of the interview: next version of
Scala, automatic parallel processing of collections. That's actually quite
stunning, since Scala automatically converts every _for_ statement into an
equivalent map/flamtmap/filter combination. That's pretty amazing to consider
the power that could offer for some applications on some kinds of multi-core
platforms, for essentially zero effort from the programmer.

"So you are working on the next version of Scala. Right. That should be out by
the end of the year, or January at the latest and the biggest addition, from
my perspective, will be to make collections parallel, to able to use the power
of multi cores for the collection. So that’s the next step. We actually have
that in trunk already, but because we want to be careful for the moment with
binary compatibility, to really have something, only bug fix releases, it’s
implemented in the distribution, but the release will come out in three months
or so."

------
wheaties
Martin Odersky is a God amongst men. Yes, he has a hoard of people supporting
and contributing ideas but... wow, that's all I can say. It's great to hear
the why of things rather than just reading the way of things. Thanks for
posting this.

------
primodemus
"But in fact, in the end result the Scala collection libraries are actually
unique, nobody, no other language has a library like that, where you say you
have a rich set of collection types, a rich set of collection operations, in
particular bulk operations, that take function parameters like Map, Filter,
Flat Map, these sort of things and you have the uniform return type principle
which says that every operation can be applied on a collection and yields the
value of the same collection as a result. So if you apply a map to a set, you
get a set, if you apply a map to a sequence, you get a sequence. "

Anyone knows how Scala's collections compares to C#'s linq?

~~~
barrkel
As I understand it, the operations it supports all correspond to the Func<T>
version of LINQ in C#, as opposed to the Expression<Func<T>> versions. That
is, you can do much if not all that you can in C# so long as you're passing
around closures rather than expression trees. LINQ uses expression trees to
convert the body of the closure to SQL where and when necessary. I would guess
you'd need to play around with operator overloading to simulate the same
effect in Scala, and end up with something slightly more clumsy and less
integrated (i.e. less tool support, diagnostics etc.) as a result.

