Re: Re: Shouldn't collection zip functions return streams?
Lex Spoon <[email protected]> Mon, 30 Nov 2015 10:14:48 -0500
| Newsgroups | gmane.comp.lang.scala |
|---|---|
| Message-ID | <CALM2SnbuKFQ8_zG52fw3DB--dFX9OySKLLMabCEN_U02Nutwwg@mail.gmail.com> |
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.