You don&#x27;t understand comments like this because you probably don&#x27;t speak from years (20+) of programming experience in OO languages, like I do, and because it is hard to show people certain better ways of doing things that unfortunately requires years of experience beating your head against the wall in other ways to really see it. But don&#x27;t take my word for it, here is John Carmack (hardcore C++ developer) on the topic, from this link: <a href="http:&#x2F;&#x2F;gamasutra.com&#x2F;view&#x2F;news&#x2F;169296&#x2F;Indepth_Functional_programming_in_C.php" rel="nofollow">http:&#x2F;&#x2F;gamasutra.com&#x2F;view&#x2F;news&#x2F;169296&#x2F;Indepth_Functional_pro...</a><p>&quot;My pragmatic summary: <i>A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in.</i> (Emphasis mine. That alone explains most of the bugs I&#x27;ve seen.) In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible...<p>&quot;No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn&#x27;t convenient.&quot;<p>This is a man who has coded slightly longer than I have, and IMHO he is correct on all these points.<p>I merely believe he didn&#x27;t go far enough (for example, immutable &quot;variables&quot;, which are not available in OO languages without hairy workarounds, ENSURE that the state your code &quot;sees&quot; is not tampered with &quot;from the outside,&quot; further reducing bugs), but statements like this are why I take the viewpoint I do.<p>Take the amount of time you debug as a percentage of your total programming time (and hell, we all enjoy debugging to a degree, don&#x27;t we? But what&#x27;s debugging, really? All it is, is trying to discover a state that wasn&#x27;t conceived of when the code was designed, no? That&#x27;s the whole point of your stack trace, right?). Now, chop that time in half. Would you want this? Who wouldn&#x27;t?<p><i>Yes,</i> FP is not appropriate for <i>all</i> realms where code lives. But it should most certainly fill <i>all</i> the spaces it currently does not, where its appropriateness is not out of the question.<p>I would also strongly recommend the &quot;Are We There Yet?&quot; talk by Rich Hickey <a href="http:&#x2F;&#x2F;www.infoq.com&#x2F;presentations&#x2F;Are-We-There-Yet-Rich-Hickey" rel="nofollow">http:&#x2F;&#x2F;www.infoq.com&#x2F;presentations&#x2F;Are-We-There-Yet-Rich-Hic...</a> which pretty much destroys mutability as a language-level trait, pretty much rendering it the mother of all bugs (literally).<p>Again, don&#x27;t take my word for it- here is MIT&#x27;s core CS curriculum on mutability&#x27;s dangers: <a href="http:&#x2F;&#x2F;web.mit.edu&#x2F;6.005&#x2F;www&#x2F;fa15&#x2F;classes&#x2F;09-immutability&#x2F;" rel="nofollow">http:&#x2F;&#x2F;web.mit.edu&#x2F;6.005&#x2F;www&#x2F;fa15&#x2F;classes&#x2F;09-immutability&#x2F;</a><p>Have I made a strong argument yet, <i>now</i>?<p>This is why I get upset whenever a new language comes out that does not feature FP&#x2F;immutable paradigms. If you&#x27;re new, you SHOULD be using these, otherwise you&#x27;re just perpetuating more man-years of debugging hell for people. I am tired of watching new programmers make the same mistakes over and over and over again.<p>The very length of this comment alone indicates how hard it is to communicate this AND why it sounds like preaching&#x2F;proselytizing&#x2F;trolling.