1. 3
  1.  

  2. 1

    Lazy collections in Scala – just don’t.

    1. 1

      Just why? Please provide references, articles or explanations.

      Personally I use them mostly in graph algorithms where I can’t know if the user will need the whole path or only the first few steps.

      I don’t need to compute the full bfs/dfs of a possibly infinitely large graph when the user well get only the locations accessible in 2 or 3 steps…

      1. 2
        • Historically, the have been extremely buggy.
        • They are still incredibly hard to use correctly.
        • Having a “lazy” data structure is a cool party trick, but the the complexity of a data structure that is lazily evaluated, buffers computed results and does three other things at the same time – just isn’t worth it.

        It’s all a big design flaw, originated by the misstep of making the “standard” mode of evaluation in Scala eager and then trying to deal with the fallout by crafting on alternatives on top of the existing API design.

        1. 1

          Your reply advocates more for full laziness in place of avoiding lazy collections. Thanks for the explanation of your point of view

          1. 1

            Yep. Scala pretty much boxed itself into a corner by wanting that all the map, filter, flatMap stuff returns the input collection again.

            With that design, the only way to get laziness into “mainstream” collections (e. g. not view API) was to make the collection itself lazy.

            That turned out to be pretty bad, as it made every operation unreliable as Stream/LazyList also doubled as a generator for unlimited elements.

            It’s one thing to get a Seq and call size, and accept that based on the actual implementation the O might differ – and something completely different to have it hang and terminate your application.