5 ms·
The article describes functional programming in its purist form: 0 side effects. In practice that simply doesn't exist in any language except Haskell and maybe
by suff 9y ago
The article describes functional programming in its purist form: 0 side effects. In practice that simply doesn't exist in any language except Haskell and maybe variants of LISP. Next is the simple fact that a pattern or functional idiom has never and will never save your project, so adopting it for those reasons is simply not practical. Also it is not practical to reduce your hiring pool by one or more orders of magnitude. No profitable company you've worked with this week relies completely on functional programming. All of the most profitable companies in the world have side effects in their code. Deviate from the path at your own risk.
- RangerScience 9y ago> 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 agoPragmatically 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 agoThe 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 agoEntities 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.
- seanwilson 9y agoWell, there's languages like OCaml where you can have mutable state if you want. If you can avoid state in most of your code and isolate it to small parts it'll still be worth the benefit. Imperative languages are all pushing immutability as a good thing now but at least with functional languages immutability has always been the default and good defaults can have a big impact.
- quickthrower2 9y agoAu contrair. Recruit for a Haskell job and you'll need a stick to beat them off! But if you need a kilotonne of developers stick with a mainstream language.