Why is functional programming the new thing suddenly? Why are industries also vouching for it and slowly shifting from pure imperative code to as much functional as possible.<p>And I am not talking about functional languages like Haskell, OcaML, etc. It is the style of avoiding state wherever possible.<p>I get it that academia has been programming functionally for quite a long time. Academia do many things that seem weird at the moment but later may become fruitful in practical settings.
Because side effects cause bugs and make code harder to reason about.<p>The ways we avoid side effects can be inefficient. Tools such as immutable data types. In the past it wasn't really worth the performance trade off. Now days we're often running in environments where raw speed is not achieved on single core performance but over distributed systems. All of a sudden immutability seems to make more sense. Not only does it help with removing side effects but it also helps parallelize workflows.<p>I think that's why its happening now.<p>I've recently switched to using F# where I can and it's been a huge win. The bug count is way down, I can refactor with confidence, and My code is more readable.<p>The learning curve was hard. I still am not sure I truly understand what a Monad is but I can see the pattern and use it as a tool. It feels more constrained at first but it brings order to chaos.
I think John Carmack called it right. It just makes sense if you are dealing with a lot of complicated state in situations where side effects on state can cause some really hairy issues (threading, memory, real time behavior, etc.).<p>So, a lot of languages have adopted the more popular mechanisms for doing things in a functional style from each other. Even Java has had lambda functions and streams for a while now. And it seems like a popular feature. And of course John Carmack was talking about this in the context of C++. If you are going to do stuff with elements in a list, you might as well use something called map. Is that functional programming or just common sense?<p>So, the short answer is "because it works and adds value". Of course, people tend to get carried away with being pure and pedantic a bit around this topic. And never mind things like monads, which brings out all the arm chair philosophers. But some of that stuff is pretty neat and not that complicated.<p>The role of academia is to move the field forward and experiment with different ways of doing things. Not all of those things work well in the real world. E.g. logic programming (prolog) is cool but ultimately never really caught on. And there have been quite a few dead ends with whole families of languages just never really getting a lot of traction only to see later languages embrace bits and pieces of it. The influences of other languages on javascript for example is fairly interesting.
IMO, there are a few things going on here:
1) iteration patterns. It’s much simpler, easier, and less bug prone to reason about programs that use map, reduce, and foreach to iterate over collections than it is to reason about programs iterating over collections with for loops. This makes it easier to test and maintain programs over time with minimal regressions<p>2) distributed computing, our general frameworks and performance reasoning has led us to a place where local state is generally not used in the types of places it used to be. Things (like query results etc) are cached in distributed data stores, not in heap memory. This leads to a more functional style.<p>3) people feel burned by the old school j2ee style enterprise object oriented programming and do not want to create or maintain “XXXfactorywhatever” classes or have deep preinstantiated object pools to do a simple thing. FP is a way to avoid those design patterns.
I can tell you about my experience using JAX- a functional Deep Learning framework.<p>My work is full-time PyTorch. I use tflite for hobby work in Edge AI.<p>I really like using PyTorch and the experience is far superior than using TF.<p>But JAX is on another league altogther. Purely functional approach to Deep Learning makes so much sense, and I personally find this approach really better and gives me more peace of mind.<p>When working with large datasets, and many kinds of transformations, and passing those through functions, thousands of times- one can't help appreciating the whole functional framework. It is so much simple and effective. And I don't need to tell you about the advantages with parallel processing.<p>And it is not with Haskell or an ML language I had my functional enlightenment- but it was with JAX.<p>In my limited exposure, much of Haskell examples and use cases I found are related to some form of text processing- an area in which I am least interested. (Please be kind if I am saying something inaccurate.)<p>So, JAX is not only a good approach to Deep Learning, but finally made me appreciate the functional paradigm.<p>When getting started, I also wrote a Notebook [0] where I wrote a beginners' guide for JAX. Head over there if you are interested. It was written after my first exposure to JAX.<p>[0]: <a href="https://www.kaggle.com/code/truthr/jax-0" rel="nofollow">https://www.kaggle.com/code/truthr/jax-0</a>
State makes things hard to manage. The more state there is in a program, the more things there are that can go wrong. If you can minimize state and express as much as possible in pure functions, then it's also much easier to write tests with well define inputs and outputs, and if anything causes problems it's easy to see which section caused it because all state originated from a single source.<p>Thus, stateless design style is easier to test, and even high level tests are more useful because of their high specificity when analysing test failures.
Seeing how you are only referring to the most basic of functional programming tenets (stateless functions), it's through a lot of experience with complex, heavily abstracted systems that plenty of software engineers have been bitten by silly bugs resulting purely from inability of different people to sanely follow otherwise complex code.<p>Move to natively distributed architectures (eg just running two single threaded app instances on the cloud gets you there) has organically driven that complexity up by a lot.<p>After you realize that it's perfectly possible to build complex and performant systems out of purely stateless components, things like DDD and functional programming suddenly start to make a lot more tests.<p>Oh, and 2h test suites which are incompatible with TDD approach ;)
Functional programming is not new.<p>OOP still exists only because of institutionalization. Outside of embedded systems there is no other good reason to continue OOP for new applications at this point.<p>OOP was invented with SIMULA76 in 1976 but was popularized with C++ in 1982. The primary benefit of OOP allows developers to scale applications via inheritance which conserves memory. The idea is to instantiate an object in memory and extend that object as necessary on child instances with memory duplication. At that time, 1982, memory was about $1700 per meg and most computers were operating with 128kb total memory.<p>Most modern languages use garbage collection: Java, JavaScript, Go, C#, and many more. In a garbage collected environment you, the programmer, are completely removed from memory management. Modern languages also prioritize speed over memory conservation because modern computer have tremendous amounts of available memory.<p>OOP increases complexity compared to functional programming. Complex means many, not challenging. This is objectively provable by counting.<p>The reason why OOP remains popular is because it is taught by universities and most programmers are produced by universities. Universities continue to teach OOP primarily in response to a broken feedback loop. Universities produce developers primarily reliant upon OOP because that’s what industry says it needs because that’s what’s available from the universities.<p>There is no motivation for universities to prioritize other programming paradigms when their stature is determined by ratings based upon industry demand. Ratings, and thus rankings, determine how much money a university can generate. Although most universities are nonprofit organizations revenue remains a primary consideration of all activities both athletic and academic.<p>It is nearly impossible to impose functional considerations as first principles in the work place. In open source or personal projects the owner of risk is the person writing the code. At work it’s all about hiring flexibility and least common denominator.
As someone who dabbles in code without too much of an idea of what he is doing, using pure functions whenever possible helps me reduce cognitive complexity and makes the code more easily testable.
To ask OP's question again a bit differently:<p>1. Is functional programming really spiking in popularity right now?<p>2a. If so, why <i>now</i>, when the principles (and implementations!) were already devised and usable so long ago?<p>2b. If not, what might give many HN commenters the false impression that functional programming is recently, acutely on the rise?
I don't think this is as new as you're suggesting. Mythical Man Month, from 1975, mentions side-effects in functions as a problem. Even lambda calculus is functional programming. Recursion existed before loops.<p>I'd say that it's actually a (relatively) more recent phenomenon that OOP took over the world.
(IMO) Functional Programming is simply better. It took a while because:<p>1. This is hard to prove<p>2. Most developers are not interested in switching paradigm when they are busy getting work done
I don't think what OP refers to is a functional language. Having synthetic sugar to write lambdas or chaining does not make C++ or Rust a functional language.<p>Despite being very vocal in the academia, use of Haskell, ML and ocaml in the real world is barely measurable. Yeah sure, I bet you know a very niche project witten in clojure but how common is that?
I can't see how functional programming is becoming popular. I see how functional programming paradigms trickle down in more popular programming languages like C#, Javascript and Kotlin but I don't see functional languages making much progress towards adoption.<p>And apart from small circles in academia, they mainly use Java and Python.
Speaking from experience, I think it makes much more sense for some kind of computation. If you do DS/ML stuff in R / Python / Julia, it is much more naturally expressed as pipes through functions. If you do data plumbing type work generally speaking.<p>I personally find OO modelling difficult when the requirements are vague. It pains me to have to re-model a dozen times as I better understand the entities involved. There's less of all that when you're just pushing structs through functions.<p>But if you were making an agent based simulation, or something where you are expressly trying to model entities doing stuff as a primary raison d'etre, OO makes much more sense.
There is a big difference between adopting functional programming language features, and FP languages "becoming popular".<p>In actuality, it is bad news for FP fans. A couple immutable construction features for parallel stuff does not mean Java 20 will have monads and can have its syntax described in four equations on a t-shirt. Closures do not mean that postfix and s-exprs are taking over Python syntax or Javascript.<p>The imperative langs are for the everyday programmer, people that have fallen to the wayside at some point in the IQ totem pole of comp sci, something like:<p>1) pointers / visualizing Von Neumann architecture to a basic level<p>2) recursion<p>3) monads<p>THere are a couple other "filter concepts" that I can't recall on a Sunday Morning, but basically Visual Basic / Excel VBA and their ilk is for people that can't do #1, Java really doesn't have recursion techniques in the core library and I've never seen anyone besides me use it, so that is kind of where #2 ends. That's probably 70-80% of people paid to program!<p>People that can understand recursion, datastructures, basic algorithms, those are "I majored in computer science undergrad", but maybe monads are a bit exotic / too late in the sequence. That may be 90-95% of programmers.<p>People that can understand monads and pure FP? 5% may be generous.<p>Somewhere in there is the dividing line between people that can visualize parallel processing and those that can't. Honestly that might be pretty close to "the recursion line".<p>The good news is FP is contibuting to the art and practice of general programming. The bad news is that "real" FP is as far from mainstream adoption as it ever has been.
My introduction to functional programming, which I have embraced, came from the JavaScript community.<p>This is ironic. Supposedly, academia is where thought leadership comes from. In fact, much of a generation of university-trained software engineers have been subjected to a parochial form of education that centered on sink-or-swim Java projects while eschewing JavaScript as unworthy.<p>The React framework has been a driving influence behind recent industry movement toward functional programming, I suspect. It handles asynchronous UI events nicely by making the UI a pure function of the state. For me, and perhaps for many others, this structure was a breath of fresh air. Popular JavaScript linting policies —- also developed in the industry —- have further coached me into preferring functional programming styles, which have turned out to offer a lot to love.
"suddenly"? Yes it has become popular overnight in 30+ years.<p>I'd chalk it up to two aspects - strongly typed languages that show how to do safe composition at scale, and .... Compositionality at scale..<p>One example, lambda calculus in which functions are the only "thing" shows that all "abstractions" can be understood as "beta abstraction" ... Which is formally defined. Other paradigms (like OOP) don't provide such a formal abstraction notion.<p>Shameless plug on that "Beta abstraction for bottom up theory building" [1]<p>[1] <a href="https://sriku.org/blog/2016/02/06/beta-abstraction-for-bottom-up-theory-building/" rel="nofollow">https://sriku.org/blog/2016/02/06/beta-abstraction-for-botto...</a>
John Hughes why fp<p>Worth a read periodically IMHO<p><a href="https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.pdf" rel="nofollow">https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...</a>
Why was OOP popular for so long? Tech is a fad driven industry. If you're asking <i>why</i> tech is a fad driven industry, that I'm less sure about. There have been lots of theories over the years. Some think that education drives most of it[0]. Others think it's the tech consulting space that drives it. Both of those things are dependent on regular sales cycles to make money and having a new "ground-breaking paradigm" to sell every 5-10 years makes it easier.<p>[0]: In this case, education includes anybody teaching programming. This includes academia, youtubers, online courses, etc.
It’s interesting that so many of the comments are basically, “it’s objectively better in every way, and the people in industry who aren’t using functional languages are too short sighted, greedy, or dumb to see it.”<p>Could be, but every time I’ve heard academics talk about an industry practice with this level of contempt, they’ve been missing something really obvious. What is it in this case, that syscalls break the purity model in any non trivial real world use case? That performance isn’t actually up to snuff with these runtimes?
Culture mist. When you were born in c++ and then java fad cames along.. you just can't see other ideas.<p>Also the FP world can be cryptic or alienating at first.
Also the tooling has improved a lot, making functional programming accessible to people outside of academia. A good example of this is Elixir/Phoenix. Ruby “wowed” everyone with their “Create a Blog in 15 min”. Now they did the same with “Create a real time twitter in 15 min”.
>I get it that academia has been programming functionally for quite a long time. Academia do many things that seem weird at the moment but later may become fruitful in practical settings.<p>On the hand isn't this obvious?<p>If their job is to push the world ahead, then some of them will actually succeed at it
1. Hype over Rust.
2. Pragmatism because of the many complexities with imperative programming and multi-tasking in a more and more multi-core world.
3. Hype over Rust.<p>:-)<p>I personally find Rust so ugly that I refuse to learn it. I don't understand why things like "let mut" are even allowed to exist. Why not simply "create" or "var" for "let mut" and "define" or "def" for "let"?<p>I am not trying to start a flame war, rather I believe I'm documenting my own ignorance of Rust, the language which I believe you are subtly referring to. I tend to learn languages from an aesthetic angle: If they look beautiful and practical to me (like Python with type annotations), I learn them. Otherwise I steer clear of them while waiting for the world to become ecstatic over them and cool down again a few decades later.