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.