I tend not to worry about lazyness at all, just trying to write data processing code in the stream processor style (you can do that without fancy libraries). The compilers are pretty smart nowadays.
There were two times when I had to think about lazyness: A search tree constructor for genomic intervals (replacing annovar) which needed strict I/O. This was one of my first non-trivial Haskell programs. The other time was when I wrote a library for arbitrary probability distributions over arbitrary types (probability distributions form a monad!). That one relied on exact real number computing and hence infinite data structures. The integer overflow is an embarrassingly simple bug. It also exists in the FastX toolkit. This is what prompted me to write my own, flexible histogram constructor of type Ord k => [[k]] -> Data.Map.Map k (Data.IntMap.IntMap Integer) for counting things of type k in a sparse table (The IntMap indexes the columns). I used it for nucleotide distribution in Fastq files, among other things. Olaf > Am 23.07.2015 um 17:02 schrieb Adam Sjøgren <a...@koldfront.dk>: > > > What is your experience, do you grow an intuition about when to worry > about lazy/strict, or how do you think about it in the day-to-day > programming? > > > Best regards, > > Adam
