4 ms·

> The article describes functional programming in its purist form: 0 side effects. Incorrect, reread the first two paragraphs: > Of course one can define func

> The article describes functional programming in its purist form: 0 side effects. Incorrect, reread the first two paragraphs: > Of course one can define functional programming so that no local mutable state and no side effects are possible, and then point out the obvious disadvantages. But that's perhaps a "no true Scotsman" kind of argument. If you would define object-oriented programming with the same strictness, everything that is not an object and uses mutable values would be forbidden. Even something such as y = sin(x), copy-on-write or returning constant objects or containers from a function would be off-limits. That is, I am asking with a very pragmatic definition of FP in mind! > What I am wondering is rather, do you observe pragmatic functional programming as John Carmack described it here as valuable? And of course this question goes also to people who have tried it to some extend, as a purely theoretical discussion would be boring. I am interested in good examples!

seanmcdirmid 9y ago
Pragmatically speaking, most non trivial programs consist of functional and, yes, even object-oriented styled code. Doing functional programming over those nounish state-indexed things doesn't make them non objects even if you prefer to call them "entities" instead, while most OOP programmers use lambdas freely without any feelings of regret.
- eyelidlessness 9y ago
  The thing about OOP that is avoided in FP isn't calling an entity an "object", it's the fact that the same object changes over time. It's hard to reason about "I let this so-called function change a thing and I can't know how or why". It's much easier to reason about "I gave this function a piece of data and it gave me the change back".
  - seanmcdirmid 9y ago
    Entities externalize state that can vary over time. So it isn't f(g) but f(g(t)). Time (and hence mutation) really does exist, whether it is implicit or explicit. It is only easier to reason about when the data you give the function is limited. You can always pass the world into the function and take it as an output, then it no longers matter. Effect systems are also possible with objects as well, they just aren't a feature of functional languages.

seanmcdirmid 9y ago

Pragmatically speaking, most non trivial programs consist of functional and, yes, even object-oriented styled code. Doing functional programming over those nounish state-indexed things doesn't make them non objects even if you prefer to call them "entities" instead, while most OOP programmers use lambdas freely without any feelings of regret.

eyelidlessness 9y ago
The thing about OOP that is avoided in FP isn't calling an entity an "object", it's the fact that the same object changes over time. It's hard to reason about "I let this so-called function change a thing and I can't know how or why". It's much easier to reason about "I gave this function a piece of data and it gave me the change back".
- seanmcdirmid 9y ago
  Entities externalize state that can vary over time. So it isn't f(g) but f(g(t)). Time (and hence mutation) really does exist, whether it is implicit or explicit. It is only easier to reason about when the data you give the function is limited. You can always pass the world into the function and take it as an output, then it no longers matter. Effect systems are also possible with objects as well, they just aren't a feature of functional languages.