> How can this paradigm be used to build predictable software that works as intended when we have no guarantee when and where an expression will be evaluated?

> How can this paradigm be used to build predictable software that works as intended when we have no guarantee when and where an expression will be evaluated? s/an expression will be evaluated/commands are fired/ reveals the latent imperative mindset. FP programs are designed by laying out, not unlike how train tracks are laid out, transformations from input to output. Some of these transformations are too complex to get right all at once, so they get broken down into smaller ones which are then composed together. (Obviously, there are other reasons why composition is a win.) An FP program "works as intended" because the transformations from input to output are correct. In high-end software some, possibly even all of it are rigorously proven correct using mathematical reasoning. The two main ways of correctness reasoning about transformations is with strict or with non-strict semantics. Time/space usage, i.e. the performance characteristics, is treated as an operational concern. That's when the nitty-gritty of eager and lazy evaluation come into play. The bottom line is that if all time is spent stressing over evaluation, you're optimizing prematurely.