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

Simon Ochsenreither <[email protected]> Sun, 29 Nov 2015 13:20:11 -0800 (PST)
Newsgroups gmane.comp.lang.scala
Message-ID <[email protected]>

> 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 "it's not such a big deal" is the conceptual change 
of having an 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.