4 ms·

Martin Odersky on the Future of Scala

47 points by fogus 16y ago

wheaties 16y ago
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 16y ago
"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 16y ago
  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.
- deleted 16y ago
  [deleted]
unoti 16y ago
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."
unoti 16y ago
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.

47 points by fogus 16y ago

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 16y ago

"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 16y ago
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.
deleted 16y ago
[deleted]

unoti 16y ago

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."

unoti 16y ago

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.