<story><title>John Carmack on Functional Programming in C++ (2018)</title><url>http://www.sevangelatos.com/john-carmack-on/</url></story><parent_chain><item><author>seanalltogether</author><text>&amp;gt; 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.&lt;p&gt;I think this probably the most important concept for programmers to keep at the front of their minds when working day to day. So many of the problems I see come from developers (myself included) adding new business logic to a process, or fixing a bug and not thinking through the side effects of the change</text></item></parent_chain><comment><author>mightybyte</author><text>It took me awhile to realize but this is one of the big things that algebraic data types (ADTs) help you to do...design your data types so they have exactly the number of valid states that your domain has.  To use another common FP way of saying it...make invalid states unrepresentable.</text></comment>
<story><title>John Carmack on Functional Programming in C++ (2018)</title><url>http://www.sevangelatos.com/john-carmack-on/</url></story><parent_chain><item><author>seanalltogether</author><text>&amp;gt; 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.&lt;p&gt;I think this probably the most important concept for programmers to keep at the front of their minds when working day to day. So many of the problems I see come from developers (myself included) adding new business logic to a process, or fixing a bug and not thinking through the side effects of the change</text></item></parent_chain><comment><author>louthy</author><text>&amp;gt; adding new business logic to a process,&lt;p&gt;Adding logic is the smallest part of the problem: adding types, that aren&amp;#x27;t constrained to represent the smallest set of values needed for the problem at hand, that&amp;#x27;s the biggest problem.  This &amp;#x27;looseness&amp;#x27; doesn&amp;#x27;t show up as a compilation error and looks on the surface to be just fine.  Then the real-world comes along and creates a value that should never exist and the code falls over.&lt;p&gt;Constraining the data by properly defining types is the (primary) way to reduce the possible states an application can get in.  This can be via sum-types (discriminated unions), or even making sure you don&amp;#x27;t use `int`, `string`, etc. and other types that are just one step away from being dynamic.&lt;p&gt;When doing &lt;i&gt;pure&lt;/i&gt; functional programming, along with properly constrained types, you tend to find the code &lt;i&gt;writes itself&lt;/i&gt;.  What I mean by this is that it becomes very much about composing functions via &amp;#x27;type lego&amp;#x27;.  Once the types fit, your code works [1].  This is a very profound feeling once you grok it, because it gives oneself a feeling of confidence in ones own code that doesn&amp;#x27;t happen in imperative land.  I will sometimes go days or weeks without even running the code I&amp;#x27;m writing because I just have confidence in it.&lt;p&gt;[1] It&amp;#x27;s still possible to write logic errors, but they&amp;#x27;re the only major class of bugs you get really.</text></comment>