Re: Re: Shouldn't collection zip functions return streams?

> If you have followed the various alterations of the Akka Streams syntax, 
> and the existence of two layers of specification, and so on, I am surprised 
> you say "it's not such a big deal".  They're trying, and it's getting 
> pretty good, but it's _hard_.
>

What I referred to with "map/flatMap/filter/groupBy/join/... API" is the 
conceptual change of having that API doing various things depending on the 
implementation vs. just describing the computation. I didn't intend to 
diminish anyone's contribution. One part why things are hard is because 
everyone has to reinvent their own wheel, having to re-solve things that 
have already solved elsewhere. Implementations should be able to focus on 
their actual goals instead of having to roll the nth 
map/flatMap/filter/groupBy/join/... API.

I think it's a great thing to have, but it looks like a big deal to me.  
> And I think it's an open question whether the cognitive overhead is larger 
> than eager computation with assignment at-will of intermediate results to 
> vals.
>

I think being able to keep one API in your head instead of half a dozen, 
which are all slightly different, is worth the benefit. I'd say it would 
tremendously lower the cognitive overhead involved.

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.