This is an interesting read. One part jumped out at me (sorry for the long quote) The purpose of the technical problem was to assess more directly candidates ability to write Haskell programs that can be used to solve real world problems, where memory usage and performance are important. The problem was all about evaluation order and memory behaviour. We started by asking candidates to look at a short program and say…
I don't see why strict:lazy::automatic gc:manual memory If anything, I would say strict:lazy::manual memory:poorly optimized GC. The compiler should be able to reorder the structure of expression expansion.
Replace "lazy" with "non-strict" and I think you're on to something. Strict and lazy both specify a particular evaluation order, but you are talking about leaving the evaluation order unspecified and letting the compiler or runtime decide which evaluation order is best.
I love today's GC, which allows me to mostly forget about memory management, but if GC still meant waiting hours for a collection I would be more inclined to manage my own memory.
Clojure's lazy sequences, combined with doall to force strict evaluation when you want it, seem like a nice compromise for now, but will likely seem archaic when a good evaluation-order optimizer is developed.