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

Ian Nowland <[email protected]> Mon, 30 Nov 2015 10:31:36 -0500
Newsgroups gmane.comp.lang.scala
Message-ID <CAGCWg7GKreGGaHHyy4_wSzKgAM5MZpUK-1u92pUuxw-AEhRpUg@mail.gmail.com>
Well, that's why I proposed that what the zip returns is a Stream. By
changing the type, it's much more explicit about being lazy.

On Mon, Nov 30, 2015 at 10:14 AM, Lex Spoon <[email protected]> wrote:

> Programmers need to know when an operation is strict or not. It will help
> if the collection libraries have some simple way to know, and not just
> decided differently for each operation on a case by case basis.
>
> This may be surprising, but many good programmers choose strict as a
> default, and only use lazy operations if there is a specific reason for it.
> The reason, at least for me, is that I want to make changes to software and
> be able to predict the performance impact. For people who like that style,
> it is nicer if everything is strict unless the collection has been
> explicitly converted into a lazy view of some kind.
>
> I've written a lot of SQL and Datalog code, and I've worked a fair amount
> on Datalog engines. In my experience, heavy optimization across a whole
> query, or worse the whole query library, makes performance very mysterious.
> You make a small change, and your performance will suddenly tank. To
> recover performance, you either change things around randomly, or you use
> tools provided by the system to understand why it made the optimization
> decisions it did. Either way, programmers end up spending a lot of time
> studying what the optimizer did.
>
> If you decide as a tool provider to use non-local optimizations, or even
> just laziness, it is a huge help to developers if you also provide a
> debugging tool for understanding the optimization decisions. In the Google
> Web Toolkit, we sensed a big increase in user happiness when we added a
> "Story of Your Compile" for debugging bad optimization of two subsystems:
> the code splitter, and the serialization system.
>
> For lazy zip, I'm not sure what such a tool would look like. A dynamic
> trace of some kind. For staged queries, a branch - off subtopic of this
> thread, it really helps to have a way to print out the query plan.
>
> Good luck, those working on it.
>
> Lex Spoon
>
> --
> 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.