<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>Kutta</author><text>I disagree with some of the sentiment expressed in the article; mostly functional programming works much better than profoundly non-functional code, and more functional programming usually delivers marginal benefits.&lt;p&gt;The fact that effects can be used to simulate other effects does not imply that programmers would typically try doing that. In fact, programming style is more often shaped by trivial inconveniences (often syntactic, or the availability of certain libraries) than most of us care to admit. A programming language that merely &lt;i&gt;discourages&lt;/i&gt; people from writing spaghetti code should still cause less spaghetti code being written. Freak bugs will pop up from time to time, but not as often.&lt;p&gt;Shifting an existing language to a more functional style should be a net negative thing only if the resulting extra complexity and bloat gets excessive. Starting from an OOP&amp;#x2F;imperative position, it gets harder and harder to support an additional (marginal) piece of FP functionality, and after a while it&amp;#x27;s just better to start over and switch to pure FP, but current OOP languages flirting with FP are not particularly close to that point. They haven&amp;#x27;t started in earnest to introduce purity to an impure core language (which would be rather awkward, as the article points out). In this situation it is somewhat early to talk about mostly functional programming not working.&lt;p&gt;Scala might be closest to the point of excessive bloat, but I&amp;#x27;m not really familiar with it, and I think that the FP support there is a good thing, especially in contrast to the Java code that it might displace.&lt;p&gt;(Disclaimer: I program chiefly in Haskell and I love it).</text></comment>