Live data from Hacker News

Critique of Lazy Sequences in Clojure

clojure-goes-fast.com

51–52 of 52 posts

Re: Critique of Lazy Sequences in Clojure

#51
post #20
post #13

This article is somewhat puzzling for me. On one hand, the OP clearly knows Clojure very well. The disadvantages of laziness are real and well described. On the other hand, though, this sounds like a theoretical/academic article to me. I've been using Clojure for 15 years now, 8 of those developing and maintaining a large complex SaaS app. I've also used Clojure for data science, working with large datasets. The disa…

> Laziness does not bother me, because I very rarely pass lazy sequences around. Sounds like that is going to the point the article is making - the best way to use lazy sequences is not to. Lazy sequence bugs make for a miserable experience. Clojure already has an onboarding problem where every new learner has to discover all the obscure do- and don't-s and go through the lessons of which parts of the language are mo…

> the best way to use lazy sequences is not to

I disagree — I do use lazy sequences, I just rarely pass them around. Very few functions in my code return lazy sequences, and those are usually the "sources": functions that can return database data, for example.

Most of the code does not return lazy sequences, and thanks to transducers can be abstracted away from the entire notion of a sequence.

Re: Critique of Lazy Sequences in Clojure

#52
I've been using the trick with enforcing realization by serializing to strings a few times. Slow, but quite useful in many contexts. However, instead of using `(with-out-str (pr ...`, there's simply`pr-str`, which is easier to remember.

I'm typically using it like so:

  (defn realize [v] (doto v pr-str))

  (binding [*some* binding]
    (realize (f some-nested-lazy-seq)))
Post reply on HN