3 ms·

You can use lazy lists / streams even with strict evaluation, you just have to be explicit.

jstimpfle 8y ago
Point being, I'd rather not have this complexity. Do you mean to explicitly take each next value from the stream? And then possibly throwing all this "lazy" work away? Or memoizing the work and writing extra code that checks if the work was already done when the data is accessed? And then probably forgetting to get rid of the data when it's no longer needed? No thanks, that's even worse. It's honest, but that doesn't make it a good idea. I like to do one thing at a time, not jump around like a wild horse. Turns out optimizing for not jumping around too much also makes programs simpler overall. I've recently cleaned up some code of this kind. Defines objects with unsuitable lifetime and tries to be smart about reusing work instead of planning out in which order to do things in the first place. While the actual task was not difficult, the code was incomprehensible, to state it in a diplomatic way.
- xfer 8y ago
  Not sure where you get all this idea of complexity from, lazy streams are used in functional languages a lot for data processing and they are not incomprehensible, also imperative languages like rust has iterators that are more used than for/while loops.
  - jstimpfle 8y ago
    Well, I described the situations from which I get my ideas of complexity... Regarding iterators, I'm fine with their usage depending on what they _do_. However I don't think it's a good idea to iterate over an abstract stream that under the hood does sorts and zips and folds. Because you lose control and understanding how much intermediate data will be produced (constant small amount? 3 times the amount?), and in what order code gets executed. And if you think consciously about the intermediate data you probably can use it for a whole lot of other things! In Haskell, unexpected memory expansions and duplication of work can happen. And these problems are not nice to debug. I might be generalizing too much, though. Maybe you're talking about short-lived web applications that never see a large amount of data, or something like that.
- tuukkah 8y ago
  For example, streams without complexity in Java: https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/util/stream/p...

Point being, I'd rather not have this complexity. Do you mean to explicitly take each next value from the stream? And then possibly throwing all this "lazy" work away? Or memoizing the work and writing extra code that checks if the work was already done when the data is accessed? And then probably forgetting to get rid of the data when it's no longer needed? No thanks, that's even worse. It's honest, but that doesn't make it a good idea. I like to do one thing at a time, not jump around like a wild horse. Turns out optimizing for not jumping around too much also makes programs simpler overall. I've recently cleaned up some code of this kind. Defines objects with unsuitable lifetime and tries to be smart about reusing work instead of planning out in which order to do things in the first place. While the actual task was not difficult, the code was incomprehensible, to state it in a diplomatic way.

xfer 8y ago
Not sure where you get all this idea of complexity from, lazy streams are used in functional languages a lot for data processing and they are not incomprehensible, also imperative languages like rust has iterators that are more used than for/while loops.
- jstimpfle 8y ago
  Well, I described the situations from which I get my ideas of complexity... Regarding iterators, I'm fine with their usage depending on what they _do_. However I don't think it's a good idea to iterate over an abstract stream that under the hood does sorts and zips and folds. Because you lose control and understanding how much intermediate data will be produced (constant small amount? 3 times the amount?), and in what order code gets executed. And if you think consciously about the intermediate data you probably can use it for a whole lot of other things! In Haskell, unexpected memory expansions and duplication of work can happen. And these problems are not nice to debug. I might be generalizing too much, though. Maybe you're talking about short-lived web applications that never see a large amount of data, or something like that.
tuukkah 8y ago
For example, streams without complexity in Java: https://docs.oracle.com/javase/8/docs/api/java/util/stream/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/util/stream/p...