4 ms·
From what I've inferred from the article "better" means: easier to write large-scale, composable systems that engineers can reason about easily.
by allengeorge 10y ago
From what I've inferred from the article "better" means: easier to write large-scale, composable systems that engineers can reason about easily.
- _yosefk 10y agoIt doesn't seem easy to reason about the performance of a program under lazy evaluation. Generally there are many aspects of a system that you may want to reason about, and making it easier to reason about one often comes at the expense of making it harder to reason about another. Pure functional code, for example, makes it easy to reason about what outputs are produced from what inputs, but that is one (important) aspect among many (and to take one thing that's really simple without purity and really tough with it - consider "pure functional data structures" vs data structures in imperative languages assuming a mutable RAM.)
- solidsnack9000 10y agoLaziness is a real problem for reasoning. Reasoning about pure functional data structures in the absence of laziness isn't that difficult, any more than the many mutable data structures that have copying/rebuilding/rebalancing that takes place only sometimes. The benefit of pure functional data structures is most visible when there is some kind of sharing -- concurrency of some kind -- in which case, reasoning about side effects becomes more difficult. There are good approaches to handling in-place array update and similar operations in pure functional programming (the ST monad, for example), it's just not the default. As long as the side effect is somehow accounted for in the return value, referential transparency is maintained; we might say the return value is there to help us reason about side effects.