<story><title>“Mostly functional” programming does not work</title><url>http://queue.acm.org/detail.cfm?ref=rss&amp;id=2611829</url></story><parent_chain></parent_chain><comment><author>yason</author><text>I think that &amp;quot;Mostly functional&amp;quot; is actually the sweet spot.&lt;p&gt;Going to any extreme makes some things horribly difficult and going to another does the same for other things. So, optimally, multiple paradigms coexist in the single codebase, applied where they&amp;#x27;re most useful.&lt;p&gt;Functional programming with as many immutable bits as possible is definitely a good start. I generally do that for whatever problem I&amp;#x27;m solving: I have a model for the data and then I write (if at all possible) pure functions to transform the inputs into meaningful outputs. But then you need know where to drop the ball and move over to some other paradigm that does something else right and merely drives the functional parts from the top level.&lt;p&gt;For example, such a data analysis library can be written with minimal state and using only pure functions but if -- and when -- you need some sort of an user interface so that the program can actually be used, an imperative&amp;#x2F;procedural approach is generally the most native approach because UIs are basically I&amp;#x2F;O. If you&amp;#x27;re adding a graphical user interface, you might use object oriented approach to build the UI tree which is probably the world&amp;#x27;s most idiomatic, canonical use for OO anyway. But even those are generally driven with an innately imperative event loop.&lt;p&gt;Also, note that the different approaches or paradigms aren&amp;#x27;t language specific either.&lt;p&gt;In the first stage, languages are tools that shape your thinking into accepting new programming paradigms but at some point you have a number of different ways of thinking in your head, and you can just forget about the languages they came from.&lt;p&gt;But in the second stage, you can just think directly in paradigms: you can consider different ways to build different parts of your program but you might actually use only one language to implement everything. You can write functional, imperative, object-oriented, and whatever code in C. Or you can use several languages with strengths in each paradigm, depending on what trade-offs produce the best engineering in each case.</text></comment>
<story><title>“Mostly functional” programming does not work</title><url>http://queue.acm.org/detail.cfm?ref=rss&amp;id=2611829</url></story><parent_chain></parent_chain><comment><author>seanmcdirmid</author><text>Debugging a functional program is so difficult (data flow debuggers don&amp;#x27;t really exist) that equational reasoning is necessary because you want be able to fix your code otherwise. But really, mixing list comprehensions with effects is really a bad idea, and we C# programmers have no trouble avoiding it.&lt;p&gt;There are ways to tame side effects without going monads, which don&amp;#x27;t really fix the complexity problem anyways (it just makes all effects explicit). See this paper for ideas on how to do that:&lt;p&gt;&lt;a href=&quot;http://research.microsoft.com/pubs/211297/managedtime.pdf&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;research.microsoft.com&amp;#x2F;pubs&amp;#x2F;211297&amp;#x2F;managedtime.pdf&lt;/a&gt;&lt;p&gt;We shouldn&amp;#x27;t treat state like an unwanted but necessary evil, we should embrace it and deal with it.</text></comment>