Also happened to be the guy who wrote the most Scala code on the planet, and he quit Typesafe last year.
Anyway, shit happens, gaps are filled. Languages, once established, are larger than any one developer, no matter how brilliant the individual may be.
It's worth noting that @paulp is as active as ever in Scala, working on his new collections library and contributing to Scala now from the outside -- he may have left Typesafe but has not in anyway left Scala. As he says, he has a "sickness" for language perfection, and fortunately for we Scala users, Scala is the target of his illness ;-)
Quit what? He is still a ghc developer. He quit his job at Microsoft Research to go work at Facebook, but that doesn't seem quite comparable to quitting a job working at the official scala company on the official scala compiler.
Not saying he's joined the dark side like Erik Meijer, but he's also not actively _working_ on the compiler as he did before; that's for the new guy(s).
And? Before that he was full time at Microsoft. He was never an employee of any sort of official ghc company working on ghc full time.
>Not saying he's joined the dark side like Erik Meijer
What dark side and what is wrong with Erik?
I love the way he assumes that. I think he may be surprised to learn the sheer scale of some production Scala systems which aren't part of the Scala class library or compiler.
Besides, he put together a list of obscure corner cases that no practicing Scala developer actually seems to care about.
On the other hand, while the ParSeqViewLike example is a bit of an inside joke (I think). It doesn't take a whole lot of doing to push the Scala collections library into weird and terrifying behaviour. I'm a practising Scala developer and I do it at least monthly. For people with experience with other better designed collections systems the Scala collections library feels heinous to use, and if you ever have to dig into the code, good luck.
If the Java stream api is implemented well and has a high take up rate, I expect lots of people to come to Paul's point of view with regards to the terribleness of the standard Scala library.
I'm genuinely curious to see examples you've seen in production code. I've used the collections for years coding full-time and haven't encountered anything like that.
From MapLike.scala def apply(key: A): B = get(key) match { case None => default(key) case Some(value) => value }
From HashMap.scala def get(key: A): Option[B] = { val e = findEntry(key) if (e eq null) None else Some(e.value) }
That is to say that the default behaviour of a Scala hash map is to create a new object for every access (notice I say access, not for every insert) even when I ask it to pretty please give me the one that doesn't have the null safe Option code involved.
I frequently hear that memory/performance are "implementation" details and don't have bearing on functionality. For my use cases that isn't true.
Even if it was, the surprising upside down nature of that API (de reference the option, instead of wrap the reference) is of itself weird.
This is just the most terse example of oddities in the library I've encountered. Other's include streams being created (and not GC'd) when they weren't necessary, collections losing performance characteristics due to the monadic calls (IndexedSeq's passed into functions as Seq's use LinkedLists for builders instead of Vectors), etc.
Finally, I fundamentally disagree with the idea that eager evaluation should be the default in the collection library. Views mitigated this somewhat, but after working with more sane libraries, have to remember that every time is tedious (though I'll grant that is a debatable point).
If your software is not performance critical, or you aren't implementing your own collections libraries, maybe you don't encounter these problems. But for the standard library, it is a problem.
You might be interested in the AnyRefMap work being done here: https://groups.google.com/forum/#!topic/scala-internals/R4fT... Perhaps you could add your voice to the discussion if you have concerns around performance.
The AnyRefMap may be a good solution to many of my issues with the default map implementation once it is widely available. It won't help with the more general lack of cohesion in the library though.
Scala's problems are real and structural. There's very little you can do about it now that all these innocent newcomers buying into the lies of the vested interests.
Speaking of lies, besides those Paul Phillips points out, you hear these nonsense about how great Scala's explicit type declarations are, that they make your function's signature clearer and etc. These are all lies, the truth is the type inference algorithm can't unify a type because of all these type variance, type bounds and type views. All these funny emoticon symbols are actually hints to tell the type inferencer to go up or down or sideways when looking for the most generic type that satisfies a type signature.
Another lie is that Odersky will keep showing you kiddy pictures and extolling how small Scala's grammar is while sweeping under the rug that Scala's many features are orthogonal, or halfway in-betweens GCDs or have surfaces of interaction with other features that are too large.
To list a few, these are my favorites:
1. implicits. Explicitness in function decl is good but when you call them it's better to hide all these unknown implicit params/type conversion from you so you can't reason your code.
2. _. There are 12 different ways you can use them. They are not shortcuts, they are conflation of concepts.
3. The interplay between classes, case classes and traits. It's very hard for me to put this one in word, there are just so many corner cases.
4. Java/Scala interop. There's no interop. There's only 1 way op from Scala to Java.
5. case classes are just ADTs. Nope, not letting me have a param-less case class or subclass a case class doesn't make them ADTs.
6. Companion objects are sold as singleton replacements. They are only singleton replacement as a side effect of having no other suitable place to put your implicit kludges.
7. Type safety. You can't guarantee type safety if you allow mutability. Period.
8. Java compat is simultaneously sold as an advantage and blamed when problems arise. Why can't Scala just use the damn bytecodes and avoid the entire Java standard lib?
Why not just try Scala for a while, instead of making things up?
Your assumption that my criticism over Scala is because I hadn't tried it is as valid as my assumption of your disagreement with me is because you haven't tried hard enough.
I had tried Scala on multiple occasions since 2.8 came out. Every time for about 1 month to 5 months. It's impossible to explain how messed up Scala is without writing a whole book about it so I admit it's hard for me to convince you. God I miss SML and Haskell.
Maybe this guy can: