Who cares about functional programming?

I consider FP to just be one of the tools in my programming toolbox. And apply it where it will fit best. Because not every problem should be solved with FP, nor with OOP for that matter.<p>Though it is sometimes educational to apply only a single solution to all problems. Just to see how far you can stretch the usefulness of the tool.<p>A nice talk about where (and where not) to apply FP is this talk by Gary Bernhardt: <a href="https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;boundaries" rel="nofollow">https:&#x2F;&#x2F;www.destroyallsoftware.com&#x2F;talks&#x2F;boundaries</a>

Functional programming alone is not very compelling. It&#x27;s just a slightly different way of organizing your code and data, with different tradeoffs in terms of what code is easy and what code is hard.<p>If all you do is present examples of using higher-order functions and algebraic data types, people will be pretty justified in saying &quot;this doesn&#x27;t really change anything important.&quot; And that&#x27;s because it doesn&#x27;t!<p>Even in Haskell, once you learn the language, code is code. Sure, laziness means learning new ways to think about composing code, but that&#x27;s just a small detail. In the end, the things that matter are same. Everything you know about performance optimization still applies. The only difference is the look of the code used to express it.<p>You replace for loops with higher-order iteration combinators! Woo! It doesn&#x27;t really change anything. You replace goto with recursion. Big deal! It&#x27;s all the same thing. (At least in a language with proper tail-call elimination.)<p>There is no giant breakthrough happening because there really isn&#x27;t anything to break through... At least as long as all you care about is &quot;functional programming&quot;.<p>There are languages where more interesting things are going on than just functional programming, though. And those have actual promise for providing real benefits. Haskell has a type system that provides real benefits in terms of documentation and correctness. That is actually useful. But it&#x27;s not &quot;functional programming.&quot;<p>So yeah. I don&#x27;t care about functional programming. I care about things that are actually improvements.

I don’t see what the big deal is. I wrote clojure professionally for many years, full-time. It’s just as easy to write spaghetti in that language as in something more traditional.

FP tends to have a disregard for practicality, and performance especially. Yes, it&#x27;s elegant, by being abstract, but this abstraction comes at a cost.<p>After falling in love in it, I wrote a large project in F#, but eventually had to ditch it and rewrite in C#. A simple analysis of any F#-generated IL will reveal this.

I dare say the reason many people are hesitant to adopt Functional programming is that:<p>A) They aren&#x27;t, they&#x27;re probably already programming in a functional programming style. Just not in a <i>purely</i> FP language (Which I would never adopt to begin with)<p>B) A lot of FP articles come off as the musings of zealots obsessed with monads, which often barely make any sense to, well, anyone. The less sense it makes at first glance, almost guarantees people will want to avoid it. Yes, maybe <i>I</i> can understand it. But I&#x27;m (hopefully) not the only maintainer of the codebase, and trying to communicate some FP concepts back &amp; how to use them really, really isn&#x27;t easy.

Completely agree. There are a couple of &quot;killer features&quot; of functional programming that led to us adopting it both to build Dark, and for Dark itself. Immutable values makes it so much easier to reason about programs. And then removing null and exceptions.<p>The downsides: a bit of a learning curve for programmers used to OO; some classes of problems are easier with OO, though not as many as you&#x27;d expect.<p>The real downside I&#x27;ve seen is that so much valuable information is in academic papers that aren&#x27;t approachable.

&gt; &gt; To be widely used, a language should support interlanguage working, possess extensive libraries, be highly portable, have a stable and easy to install implementation, come with debuggers and profilers, be accompanied by training courses, and have a good track record on previous projects.<p>&gt; The first five of those factors, which are mainly technical, are provided by almost all of the functional languages.<p>That seems like a very generous statement. Unless the author is talking about some functional language I don&#x27;t know.<p>Is there an FP language which <i>really</i> has the extensive libraries of Java &#x2F; Python &#x2F; C++ &#x2F; JS ? (You might argue with Clojure and anything with a FFI..)<p>Is there an FP that has a debugger and profiler as Visual Studio for C++, Eclipse for Java, and your browser for JS ? (No, you REPL does not count as debugger.)<p>Is there any language that as `interlanguage working` (ok, this one is unfair, only JVM and C really count...)<p>Is there an FP that has an implementation that&#x27;s not a nightmare to install ? (ok, this one&#x27;s even more unfair - <i>everything</i> is a nightmare to install...)

&gt;<i>However, looking at how discontent programmers are with Objective-C, not so much anymore. Not even the immaturity of the tooling around the language like its IDE Xcode could stop the migration.</i><p>Actually it has little to do with some huge &quot;discontent&quot; towards Objective-C, and more with Apple presenting Swift as the way forward and their main officially supported language...<p>&gt;<i>So why are most of the young contenders stuck with little recognition in their niches, while Swift is taking off so quickly?</i><p>Again, because no functional language has a huge company promoting it as THE language its devs should use, like Swift has with Apple. F# is not MS&#x27;s favorite, for example...<p>&gt;<i>For developers building applications in the Apple ecosystem, the primary hard problem seems to be Objective-C. In other words, ”the pain” is so significant that developers were almost desperately waiting for an alternative language and are now happily joining the movement of the Swift language.</i><p>Yeah, no...<p>&gt;<i>The first five of those factors [interlanguage working, possess extensive libraries, be highly portable, have a stable and easy to install implementation, come with debuggers and profilers], which are mainly technical, are provided by almost all of the functional languages.</i><p>Not really. Compared to C#, Java, Javascript, it&#x27;s not even close...<p>&gt;<i>Following the theory of &quot;The Chasm&quot;, FP would need to solve a severe problem that could not be solved with existing approaches in order to make a breakthrough (finding its &quot;killer app&quot;)</i><p>Not really. Swift doesn&#x27;t solve any special problem &quot;that could not be solved with existing approaches&quot;, C# doesn&#x27;t, Java doesn&#x27;t, and in general, most successful languages don&#x27;t.<p>They succeed because of platform stronghold (UNIX -&gt; C, MS -&gt; C++, OSX&#x2F;iOS -&gt; Swift) and other such reasons...

At the end of the day, it comes down to performance. We&#x27;ve been lucky for a long time where the hardware improvements seemed to almost come for free, but the golden age of Moore&#x27;s law is over, and people finally are realizing that their code needs to be tighter in order to achieve performance. FP doesn&#x27;t mirror how the actual machine instructions work, whereas imperative languages do. And this means that when you inevitably hit a performance wall, it&#x27;s generally easier to solve it in an imperative environment because you can already visualize what&#x27;s going on underneath (save for gc stalls or whatnot). FP has its places to shine, but without the ability to see how the sausage is made (and tweak it), you&#x27;re always at risk of an unbreachable wall.

&gt; Since the early 2000s, functional programming has become more and more popular<p>This is because pre-2000&#x27;s, OO was particularly well-suited to desktop software and dominated that space, which also happened to be a space which occupied a large fraction of total development.<p>OTOH, tasks of data transformation, which after the 2000&#x27;s became in more demand as software moved more and more from the desktop to the server, is particularly well-suited to FP (due to being on the other side of the expression problem).<p>The shift from desktops to servers has real consequences on language design.<p>Microsoft even admitted this as one of the reasons they&#x27;re trying to bolt on FP features to C#.

I architect my code in layers. Generally OO based then specifically functional based; I find that works best for me.

&gt; FP would need to solve a severe problem that could not be solved with existing approaches in order to make a breakthrough<p>So the question the author is asking is whether there is problem which can only be solved via lambda calculus and not by turning machines or at least the difference should be significant in favour of lambda calculus.<p>Since both approaches are equivalent models of computation, I have to bet on the &quot;no such killer app&quot; side.

FP is fun, but there aren&#x27;t many good languages for it. Haskell is too academic, Clojure is fun but hasn&#x27;t taken off, Scala is too complicated (Java with FP shoehorned in, who thought this was a good idea?).<p>I like FP but 90% of the time you&#x27;d be better off with just Python because other developers will be able to work with it and there are libraries. Or Golang or Node or whatever.<p>Frustrating, but it is what it is.

Please don&#x27;t fancy functional programming in javascript. Its a powerful paradigm and should be used in a language with powerful compiler.

Compilers care about functional programming in its side-effect-free form because you can only optimize code you can understand the side effects of, and side-effects generally foreclose on optimization. The most obvious example is the volatile keyword in C, and how that forces a lot of memory traffic the compiler would otherwise be able to avoid.

How the hell did Kotlin end up on the non functional list, and Scala did?<p>Kotlin code tends to be at least as functional as Scala is.<p>If Kotlin isn&#x27;t functional, then Scala isn&#x27;t, and if Scala is functional, then Kotlin most certainly is.

Isn&#x27;t FP simply too esoteric to ever become properly mainstream?

The article doesn&#x27;t mention all the programmers being (forcibly) introduced to functional programming concepts by using React and Redux.<p>Perhaps this is another possible way to jump the chasm?

Lots of words without much value, just like FP!<p>Seriously, why is this on the homepage? Doesn&#x27;t contain anything interesting about FP.