Why Not Lazily Evaluate Everything?

Lazy evaluation can delay the computations until result is actually needed, saving unnecessary calculations and providing more flexibility in control flow.

So why not lazily evaluate all computations?

While it can reduce immediate computation costs, it also postpones the occurrence of errors. In eager evaluation, errors are generally caught early in the execution; whereas in lazy mode, errors might only occur when data is actually accessed, leading to a debugging process that is more scattered and harder to trace. (Functional Programming avoids this issue by design to prevent side effects, and many FP languages have lazy evaluation as a default strategy.)

Lazy evaluation requires an additional execution model to “remember” which values have not yet been computed, which typically means more wrapping and more memory overhead at the language execution level. (Side effects can be wrapped into explicit thunks/effects and called where you control them (or use Effect / IO Monad)

Lazy evaluation is a strategy for deferring decisions, significantly improving efficiency when data streams are large and not all results are needed; however, when a predictable execution order or explicit side effects are required, eager mode is more reliable.

function* process(items) {
  for (const it of items) {
    yield doSideEffect(it);
  }
}

// The caller does not iterate => no side effects occur
const gen = process([1,2,3]);

// The side effect is only triggered when this line is executed
for (const p of gen)

• Why do most programming languages use eager evaluation for arguments passed to a function? - stackoverflow🔗
• Using Generators - Effect🔗