Closed tonymorris closed 6 years ago
This isn't really an issue with the new collections (which should be created in scala/scala at this point anyway). At best, it's an issue for scala/scala-lang, but I think changing a blog post from over a year ago would require some discussion first over on contributors.scala-lang.org.
("the main" could be interpreted as either "the most common" or "the deepest, most serious". the scary-type-signatures criticism is certainly the most common; perhaps that's all @julienrf meant.)
locking, since (as @NthPortal indicates) we're in the process of closing out the issues in this repo, now that the new collections are merged into scala/scala and included in Scala 2.13.0-M5.
https://www.scala-lang.org/blog/2017/05/30/tribulations-canbuildfrom.html
FYI, this is not the main criticism. The main criticism is that it has (almost) no fundamental principles from which to build abstractions and that those that do exist had already been done better before
CanBuildFrom
even came to exist.The primary purpose of an abstraction such as
CanBuildFrom
is to maximise the specific instances, and maximise the operations that can subsequently be derived, often trading off between these two. A bad abstraction is one that does not trade off here, but minimises in both cases.CanBuildFrom
is such a bad abstraction. There does not exist code that usesCanBuildFrom
that cannot then be improved without it using principled abstractions.Criticisms of "scary type signatures" should be ignored for maximum efficiency. They are not well-reasoned criticisms.
It is important to understand why you might consider improving code to begin with and so I thought clarifying the main criticism here is also important.