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.