Scala Collections: Why Not?

preview_player
Показать описание
Paul Phillips is a co-founder of Typesafe and the most prolific committer to Scala. He's spent the last 5 years developing the language, writing a lot of code and drawing a lot of conclusions, but has decided to walk away. In this talk, he explains why.

He outlines what he believes to be certain shortcomings of the Scala collections library. In Paul's words, "Based on my extensive experience with Scala collections, I'm writing my own. The focus is much tighter: immutable, performant, predictable, correct. The talk will alternate between why the Scala collections manage none of those things, and how I hope to do better."

A day after the SF Scala event, Paul left this comment on their meetup page, which seems relevant, "[...] I already discovered that if I say nothing about it then people will draw very incorrect conclusions about what the major issues are and why I've moved on. It's not sad, it's not happy, it's only a question of whether you want the real picture or some distant reflection of it."

Рекомендации по теме
Комментарии
Автор

Paul, thanks for all your work on Scala.

shirankao
Автор

Interesting video: if you take the complaints apart, you can learn interesting things about the Scala collections internals

CarlosSaltos
Автор

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 :(

TheRaspPie
Автор

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.

jonathanmerritt
Автор

lol... this is genuinely funny to watch. One more language gone from the check-list; I wouldn't trust a language producing THAT.

VandroiyIII
Автор

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.

vincemarco
Автор

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?

kevalan
Автор

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?

tepan
Автор

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.

abhishes
Автор

is it me or he sounds like he is going mad, he has seen stuff

FabianLopez_lomba
Автор

Now (Nov 2016) all the mentioned errors are fixed?

justpk
Автор

Also, it's weird to expect any functional invariants to hold when your "function" is something as non-deterministic as System.nanoTime %

kevalan
Автор

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.

jedichenbin
Автор

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.

NoNonsenseMeditation
Автор

Total wast of time seeing this funny gui

bulbulahmed
Автор

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 :(

TheRaspPie