4 ms·

> it combines the safety of Haskell with the flexibility of Clojure Foldable, Traversable, Monoid etc. are all far better abstractions than what Scala collecti

> it combines the safety of Haskell with the flexibility of Clojure Foldable, Traversable, Monoid etc. are all far better abstractions than what Scala collections provide, and they don't lead to unmanageable inheritance hierarchies and ridiculous APIs. How many bugs have been caused by that? A few hundred maybe? Does Set equality work in the current release or is that broken again? Is it possible to do thread safe efficient merges in immutable collections yet? The only thing Scala collections offers that Haskell doesn't is the CanBuildFrom travesty. At least in Clojure you can chain transformations together without generating tons of intermediate values. In Scala you're forced to choose between being ridiculously inefficient or using iterators.

happy4crazy 13y ago
Can you expand on the CanBuildFrom travesty? (It seems like you've got interesting things to say, but you're being a bit strident. It bums me out that Scala discussions on HN take such a heated tone.)
- profdemarco 13y ago
  CanBuildFrom is essentially a typeclass in Scala that is used for converting between collection types. Ignoring the coherency issues associated with using implicits for typeclasses, it makes the implementation of the collections library significantly more complicated and causes issues with type inference. In the rare cases where you actually need to convert between collection types, it's usually trivial and more efficient to do it manually. Essentially they've added tons of complexity for negligible benefit. One of my main gripes with the Scala collections library is that it's overly complex and that this complexity has been the source of hundreds of bugs. If there was any real benefit to the way it's currently done they wouldn't be hiding the true type signature for things like `List.map` in the official Scaladocs.
  - frowaway001 13y ago
    You are kind of either ignoring or not knowing the core use-case of CanBuildFrom. Why talk about things you don't understand?
    - profdemarco 13y ago
      The reasons other than the ones I've outlined are caused by implementation details and wouldn't exist if they chose the correct abstractions.
      - frowaway001 13y ago
        That's wrong.

happy4crazy 13y ago

Can you expand on the CanBuildFrom travesty? (It seems like you've got interesting things to say, but you're being a bit strident. It bums me out that Scala discussions on HN take such a heated tone.)

profdemarco 13y ago
CanBuildFrom is essentially a typeclass in Scala that is used for converting between collection types. Ignoring the coherency issues associated with using implicits for typeclasses, it makes the implementation of the collections library significantly more complicated and causes issues with type inference. In the rare cases where you actually need to convert between collection types, it's usually trivial and more efficient to do it manually. Essentially they've added tons of complexity for negligible benefit. One of my main gripes with the Scala collections library is that it's overly complex and that this complexity has been the source of hundreds of bugs. If there was any real benefit to the way it's currently done they wouldn't be hiding the true type signature for things like `List.map` in the official Scaladocs.
- frowaway001 13y ago
  You are kind of either ignoring or not knowing the core use-case of CanBuildFrom. Why talk about things you don't understand?
  - profdemarco 13y ago
    The reasons other than the ones I've outlined are caused by implementation details and wouldn't exist if they chose the correct abstractions.
    - frowaway001 13y ago
      That's wrong.