[lmm]

The scala collections library is the most powerful/flexible I've ever seen in a strongly typed language; it combines the safety of Haskell with the flexibility of Clojure. Given the amount of ongoing complaints I see around cabal I don't think it's fair to say it "actually works" (fwiw I'm very happily using maven to build my Scala projects, so I never really know what the sbt fuss is about). And the rate of features and other progress in recent scala releases clearly demonstrates there are plenty of people who understand the implementation well enough to modify it.

[profdemarco]

> 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]

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]

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]

You are kind of either ignoring or not knowing the core use-case of CanBuildFrom. Why talk about things you don't understand?

[profdemarco]

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]

That's wrong.

[Sssnake]

You should try haskell sometime, their version of collections is much better. Complaints about cabal are of the same nature as complaints about every package manager "hey I tried to do something that can't be done and it said it can't be done". Having used all three languages, I still use haskell daily, I would use clojure again if demanded without complaint, and I would never in a million years consider touching scala again, ever.

[frowaway001]

The last time I looked chaining collection operations still required unnecessary boilerplate and was not even the default way to use collections. Did they fix that? As far as I know, they didn't.

Additionally, it seems that moving from lists to a different collection type still involves rewriting your whole code due to the insane idea of using different functions by default (fmap/map, mempty/[], mappend/++).

I just don't have to deal with any of these design mistakes in Scala. Having sane defaults and stuff that "just works" consistently are a huge benefit.

[Sssnake]

>The last time I looked chaining collection operations still required unnecessary boilerplate and was not even the default way to use collections. Did they fix that?

I can't even imagine what you are talking about, so I can't say if they "fixed it" or not.

>Additionally, it seems that moving from lists to a different collection type still involves rewriting your whole code due to the insane idea of using different functions by default

"I did something dumb and now I don't like it". So, don't do it? Why were you using map in the first place?

>I just don't have to deal with any of these design mistakes in Scala

I don't have to deal with them in haskell either. But I do have to deal with the hundreds of other mistakes scala made if I use it.