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.