I didn’t want to insinuate that - you probably wouldn’t have recommended using iterators, if you were.
My “all in” was rather hinting at my experience that, while vanilla Scala allows rather gradual progress through the paradigm/style space, scalaz/Cats have black hole characteristics - once you pull them in, they start taking over the whole project. I’m not saying that’s a bad thing, and maybe I’ve just been holding it wrong.
This still strikes me as an very strong statement. I certainly do have issues with aspects of the Scala collection API myself, Seq
being at the center of quite some of those, but I’d still place it pretty much on the usable side - I’ve seen worse. Even if I accepted this statement for the standard API, I probably wouldn’t want to generalize this - I still don’t see what’d be wrong with a trait for finite, strict, ordered collections that basically only hides the performance differences between the concrete implementations.
The difference between Iterator
and Seq
in terms of complexity doesn’t look that striking to me. Both are traits with 2-3 base methods, lots of derived methods, among them some that allow to shoot your own foot.
Apart from length, I think I can - although not necessarily using the “obvious” methods on Seq
for this purpose. As for length, again, I don’t see the difference to Iterator
. But yes, I get and share your point.
It’s explicit and conscious, but not necessarily a decision. If I need to interop with these APIs, I need to pass my data with the type they require.
That seems to be the other point where we have different experiences. I certainly like Cats, but I’d think it comes with quite a learning curve (not just the individual concepts, but combining them in a full application), and it feels pretty much all-or-nothing to me. Thus I’d be hesitant to recommend it as a near compulsory alternative to the vanilla Scala API for everyone.