| I encountered them on a daily basis when I was doing Scala, and you see these Scala collections WTFs pretty much on every other line when you are prototyping in the REPL. I've come to the conclusion that the only way the Scala collections library will give me confidence is when my head can reason more than 100 types at the same time while having distinct types for every value in the universe. 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?