I agree with this statement.

I think lazy evaluation is very hard, especially when you are dealing with a codebase of of say 50 files with structures containing other structures, the line between lazy and strict is very hard to see.

The difficulty learning lazy evaluation skill goes from

* 0 where you know nothing to 5 where you sort of understand.

* 5 - 90 is a space where you think you know what it is, but you really don't. You'll probably get yourself in trouble more than helping.

* 90-100 is when you grok it and can use it effectively.

I am an avid haskell user for a few years and I am still 50/50 on most of my conclusions about laziness without asking someone else.

Is it fair to say that in Haskell, you have to think about evaluation order less, but when you do, it's harder?

I think it can be unexpected if you're used to other semantics, but the behavior of laziness is very well defined.

    > let x = [1 .. 100] :: [Int]
    > seq x () -- force the first cons
    > :sprint x
    x = 1 : _ -- we evaluated the first cons
    > foldr (\e l -> e + l) 0 x
    5050 -- printing this value forces foldr to complete
    > :sprint x
    x = [1,2,3,4,5...100] -- all conses evaluated

When you hit that difficult to reason about evaluation order in Haskell, it'll take that time you thought you gained.