Very insightful. Any plans for an OSS library of collections for scala that are "beautifully" designed? Doesn't seem necessary to throw away the whole language over some collection design issues. I know ... tip of the iceberg and all that. Just saying, that a solution needs to start somewhere, and I don't see any other languages coming close to leveraging both OO and FP, providing type safety, and providing a high level of interoperability with Java. Seems like an appropriate place to start. I would certainly switch over to using an OSS collections library that was easier, more straight-forward, less error prone, more consistent, and better performing.
I wonder how much time PaulP has spent with Haskell? I'm only learning Haskell at the moment (after a few years with Scala), but its emphasis on purity and its lack of subclassing seem to be just what he's looking for. I haven't gone far enough yet to see what the limitations might be of wide-ranging typeclass use, but it seems great so far.
I think his problem really is that "won't fix" bug status. If we do this, the language has no chance to fix. I always found the best about Scala not the functional constructs or other features, but really the way the language inventors want to prevent it from standing still. Everytime Martin Odersky talks about Scala and plans in the future, I have a strong feeling about Scala because I have the confidence that it will evolve. After Paul's talk I was shocked about Typesafe preventing these fixes. Scala started as an educational language, but it reached the point where Typesafe had to offer backwards compatibility and restrict evolving just because business customers required it :(
List(1, 2, 3).toSet() warning: Adaptation of argument list by inserting () has been deprecated: this is unlikely to be what you want. 123456789.round warning: method round in class RichInt is deprecated: This is an integer type; there is no reason to round it. Perhaps you meant to call this on a floating-point value?
I don't get the gripe with the hashcode of a set. I get that some elements may hash to the same thing and be counted only once in the sum, but why is that a problem?
I wonder if scala community do anything for the points raised by Phillip. I just did a List(1, 2, 3) contains "your mom" on scala 2.11.7 and it did not raise any error even though I am looking for an string in a list of int.
Paul, I don't think the example you gave about the SortedSet is valid. If you have a Set, and do `map`, the result set shall not contain the duplicated elements. That's why SortedSet(3,6,9) map f has only one element.
goawaygoawaynow What else would you expect when mapping over a set?? Anything else would be quite weird to me. In Haskell when you map over a Set of A with a function A->B you get (guess what) a Set of B.
I would expect the 'top' type in the hierarchy of that particular collection class (disregarding AnyRef, of course). E.g., Set#map should return an Iterable[B]. To see an example of this in the standard library itself, see Some#map, which returns an Option[B] (not a Some[B]).
+Yawar Amin Your Option example seems a bit facetious. Some and None are analogous to List's Cons (::) and Nil. Do you think Cons#map should also yield an Iterable? If yes, then I guess our tastes are diametrically opposed :)
Very funny, very interesting talk. Nevertheless the problem's highlighted don't seem to effect my day to day coding. I guess there needs to be a balance, like I love the fact that Lists of tuples and Maps fluidly intertwine, but Paul seems to think that kind of thing over-complicates things. And I like how ".par" gives me 4x speed up on a quad core computer - I don't want to implement my own!! As for the .view not really working, .iterator and .reverseIterator work just fine and can be used to achieve the same speedup given. Now his argument against the map associativity not working for Set and BitSet doesn't really hold because no one ever said any type with a map operation is a Functor - there is no inconsistency. Sounds like it's really painful to implement Scala and that's what he hates, but for me I find coding in Scala very pleasurable. 123456789.round is just as weird as doing 123456789.toFloat, that's not Scala that's float. The Set apply method being contains is awesome, means you can do: scala> List(1, 2, 1, 3, 4).partition(Set(1, 4)) res54: (List[Int], List[Int]) = (List(1, 1, 4),List(2, 3)) It's swings and roundabouts, but I still love Scala.
I think his problem really is that "won't fix" bug status. If we do this, the language has no chance to fix. I always found the best about Scala not the functional constructs or other features, but really the way the language inventors want to prevent it from standing still. Everytime Martin Odersky talks about Scala and plans in the future, I have a strong feeling about Scala because I have the confidence that it will evolve. After Paul's talk I was shocked about Typesafe preventing these fixes. Scala started as an educational language, but it reached the point where Typesafe had to offer backwards compatibility and restrict evolving just because business customers required it :(
Paul, thanks for all your work on Scala.
Interesting video: if you take the complaints apart, you can learn interesting things about the Scala collections internals
Very insightful. Any plans for an OSS library of collections for scala that are "beautifully" designed? Doesn't seem necessary to throw away the whole language over some collection design issues. I know ... tip of the iceberg and all that. Just saying, that a solution needs to start somewhere, and I don't see any other languages coming close to leveraging both OO and FP, providing type safety, and providing a high level of interoperability with Java. Seems like an appropriate place to start. I would certainly switch over to using an OSS collections library that was easier, more straight-forward, less error prone, more consistent, and better performing.
lol... this is genuinely funny to watch. One more language gone from the check-list; I wouldn't trust a language producing THAT.
I wonder how much time PaulP has spent with Haskell? I'm only learning Haskell at the moment (after a few years with Scala), but its emphasis on purity and its lack of subclassing seem to be just what he's looking for. I haven't gone far enough yet to see what the limitations might be of wide-ranging typeclass use, but it seems great so far.
+Jonathan Merritt or Clojure
type system is overappreciated
I think his problem really is that "won't fix" bug status. If we do this, the language has no chance to fix. I always found the best about Scala not the functional constructs or other features, but really the way the language inventors want to prevent it from standing still. Everytime Martin Odersky talks about Scala and plans in the future, I have a strong feeling about Scala because I have the confidence that it will evolve. After Paul's talk I was shocked about Typesafe preventing these fixes. Scala started as an educational language, but it reached the point where Typesafe had to offer backwards compatibility and restrict evolving just because business customers required it :(
List(1, 2, 3).toSet()
warning: Adaptation of argument list by inserting () has been deprecated: this is unlikely to be what you want.
123456789.round
warning: method round in class RichInt is deprecated: This is an integer type; there is no reason to round it. Perhaps you meant to call this on a floating-point value?
List(1, 2, 3) contains("abc") still compiles in 2023. Very loose typing.
is it me or he sounds like he is going mad, he has seen stuff
I don't get the gripe with the hashcode of a set. I get that some elements may hash to the same thing and be counted only once in the sum, but why is that a problem?
I wonder if scala community do anything for the points raised by Phillip. I just did a List(1, 2, 3) contains "your mom" on scala 2.11.7 and it did not raise any error even though I am looking for an string in a list of int.
Why it will raise an error? It gives a boolean.
I meant compiler error. Since the List is type of Int and we are trying to look for a string in that list.
Press F to pay respects
Now (Nov 2016) all the mentioned errors are fixed?
most of the problems are design issues; you cannot really fix design issues because it would break backwards compatibility
Also, it's weird to expect any functional invariants to hold when your "function" is something as non-deterministic as System.nanoTime % 1000000.
Map still looks the same. 2.4.2017
Still same 2020-07-13
The classic definition of round.
Paul, I don't think the example you gave about the SortedSet is valid.
If you have a Set, and do `map`, the result set shall not contain the duplicated elements. That's why SortedSet(3,6,9) map f has only one element.
His point here is (and it becomes clear later on) that map over a Set should not return a Set. Exactly because of this.
goawaygoawaynow What else would you expect when mapping over a set?? Anything else would be quite weird to me. In Haskell when you map over a Set of A with a function A->B you get (guess what) a Set of B.
I would expect the 'top' type in the hierarchy of that particular collection class (disregarding AnyRef, of course). E.g., Set#map should return an Iterable[B]. To see an example of this in the standard library itself, see Some#map, which returns an Option[B] (not a Some[B]).
+Yawar Amin Your Option example seems a bit facetious. Some and None are analogous to List's Cons (::) and Nil. Do you think Cons#map should also yield an Iterable? If yes, then I guess our tastes are diametrically opposed :)
Kev Alan when you have subtyping in a functional programming language, all the usual bets are off :-)
Very funny, very interesting talk. Nevertheless the problem's highlighted don't seem to effect my day to day coding. I guess there needs to be a balance, like I love the fact that Lists of tuples and Maps fluidly intertwine, but Paul seems to think that kind of thing over-complicates things. And I like how ".par" gives me 4x speed up on a quad core computer - I don't want to implement my own!!
As for the .view not really working, .iterator and .reverseIterator work just fine and can be used to achieve the same speedup given.
Now his argument against the map associativity not working for Set and BitSet doesn't really hold because no one ever said any type with a map operation is a Functor - there is no inconsistency.
Sounds like it's really painful to implement Scala and that's what he hates, but for me I find coding in Scala very pleasurable.
123456789.round is just as weird as doing 123456789.toFloat, that's not Scala that's float.
The Set apply method being contains is awesome, means you can do:
scala> List(1, 2, 1, 3, 4).partition(Set(1, 4))
res54: (List[Int], List[Int]) = (List(1, 1, 4),List(2, 3))
It's swings and roundabouts, but I still love Scala.
Total wast of time seeing this funny gui
I think his problem really is that "won't fix" bug status. If we do this, the language has no chance to fix. I always found the best about Scala not the functional constructs or other features, but really the way the language inventors want to prevent it from standing still. Everytime Martin Odersky talks about Scala and plans in the future, I have a strong feeling about Scala because I have the confidence that it will evolve. After Paul's talk I was shocked about Typesafe preventing these fixes. Scala started as an educational language, but it reached the point where Typesafe had to offer backwards compatibility and restrict evolving just because business customers required it :(