<story><title>What are potential disadvantages of functional programming?</title><url>https://www.reddit.com/r/compsci/comments/6pnq7e/what_are_potential_disadvantages_of_functional/</url></story><parent_chain><item><author>eropple</author><text>If what you care about is &amp;quot;everything is a beautifully curried function that actually doesn&amp;#x27;t do anything&amp;quot;, the concern about loops is definitely a thing (but any loop can be turned into a recursive function so long as your stack is big enough, even if they&amp;#x27;re usually hideous). But pretty much everybody I&amp;#x27;ve ever worked with considers functional purity in the logic layer to be &amp;quot;functional programming&amp;quot; at its most useful (Gary Berhardt&amp;#x27;s functional-core, imperative-shell talk is a good one). Is it easier to write with a loop? &lt;i&gt;Then use a loop!&lt;/i&gt; If that loop is contained in a pure function that has no side effects and encapsulates something that isn&amp;#x27;t the most beautiful crystalline code formation anybody ever did see, &lt;i&gt;nobody cares&lt;/i&gt;.&lt;p&gt;It&amp;#x27;s the mindset, not the implementation, that actually makes functional programming so valuable a tool.</text></item><item><author>surement</author><text>Biggest disadvantage for me comes when trying to implement a complex algorithm where the paper uses pseudocode that&amp;#x27;s imperative (which is almost always). In the best case you can implement parts of it functionally but when it comes time to put these together you will likely use some kind of loop, but that&amp;#x27;s not possible in &amp;quot;purely&amp;quot; functional languages.&lt;p&gt;Otherwise -- and in particular when coming up with algorithms -- I find it preferable for languages to be efficient with functional idioms (recursion, map, filter, etc.).&lt;p&gt;Edit: I understand that anything&amp;#x27;s possible in a functional language that&amp;#x27;s possible in other languages. My point is that conversion from imperative to functional can be complex and might not be worth the trouble, and that doing it purely functionally might defeat the purpose: it will be nearly impossible to read or incredibly inefficient.</text></item></parent_chain><comment><author>tmerr</author><text>The concern about stack space is slightly misleading since many languages, i.e. Scheme, can easily optimize such functions to use O(1) space by reusing stack frames across recursive calls. The problem is that while Scheme guarantees this tail-call optimization in the spec the are many other languages that leave it up to implementation, or intentionally omit it because they don&amp;#x27;t want to lose stack traces.&lt;p&gt;Anyway I agree with the overall sentiment, and will check out the talk you linked. There&amp;#x27;s another good one along similar lines: &amp;quot;The Clean Architecture in Python&amp;quot; by Brandon Rhodes: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;pyvideo.org&amp;#x2F;pyohio-2014&amp;#x2F;the-clean-architecture-in-python.html&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;pyvideo.org&amp;#x2F;pyohio-2014&amp;#x2F;the-clean-architecture-in-pyt...&lt;/a&gt;</text></comment>
<story><title>What are potential disadvantages of functional programming?</title><url>https://www.reddit.com/r/compsci/comments/6pnq7e/what_are_potential_disadvantages_of_functional/</url></story><parent_chain><item><author>eropple</author><text>If what you care about is &amp;quot;everything is a beautifully curried function that actually doesn&amp;#x27;t do anything&amp;quot;, the concern about loops is definitely a thing (but any loop can be turned into a recursive function so long as your stack is big enough, even if they&amp;#x27;re usually hideous). But pretty much everybody I&amp;#x27;ve ever worked with considers functional purity in the logic layer to be &amp;quot;functional programming&amp;quot; at its most useful (Gary Berhardt&amp;#x27;s functional-core, imperative-shell talk is a good one). Is it easier to write with a loop? &lt;i&gt;Then use a loop!&lt;/i&gt; If that loop is contained in a pure function that has no side effects and encapsulates something that isn&amp;#x27;t the most beautiful crystalline code formation anybody ever did see, &lt;i&gt;nobody cares&lt;/i&gt;.&lt;p&gt;It&amp;#x27;s the mindset, not the implementation, that actually makes functional programming so valuable a tool.</text></item><item><author>surement</author><text>Biggest disadvantage for me comes when trying to implement a complex algorithm where the paper uses pseudocode that&amp;#x27;s imperative (which is almost always). In the best case you can implement parts of it functionally but when it comes time to put these together you will likely use some kind of loop, but that&amp;#x27;s not possible in &amp;quot;purely&amp;quot; functional languages.&lt;p&gt;Otherwise -- and in particular when coming up with algorithms -- I find it preferable for languages to be efficient with functional idioms (recursion, map, filter, etc.).&lt;p&gt;Edit: I understand that anything&amp;#x27;s possible in a functional language that&amp;#x27;s possible in other languages. My point is that conversion from imperative to functional can be complex and might not be worth the trouble, and that doing it purely functionally might defeat the purpose: it will be nearly impossible to read or incredibly inefficient.</text></item></parent_chain><comment><author>RBerenguel</author><text>Functional API, efficient implementation. It&amp;#x27;s always a good rule of thumb</text></comment>