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_.

And they're doing as well or better than anyone else out there (AFAICT) in
giving you the tools to specify the graph, rather than saying, "Well, I can
make these tools easily, so your graph had better look like this".

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.

  --Rex


On Sun, Nov 29, 2015 at 10:32 AM, Simon Ochsenreither <
[email protected]> wrote:

>
> If you're going to go all the way to Akka Streams where you build the
>> processing graph in advance, then I agree.
>>
>
> Agree, and it's not such a big deal, other libraries do the same, too.
> It gives people much more control of execution, if they receive the
> computation and can decide on their own what's their evaluation strategy,
> instead of having to decide on this upfront (and then having to copy-paste
> code, because currently every computation is incompatible with all the
> others).
>
> --
> 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.
>

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