Lambdas are now a requirement for any modern programming language. Monadic promises are how asynchronous programming is done. Rust is basically OCaml except with typeclasses and without a GC.
Inch by inch, ideas from FP bubble up into mainstream programming.
I predict that algebraic effects (a la Koka) are next, but it'll be a while before the industry is ready for it.
To play the devil's advocate: From an OOP perspective, lambdas are just syntactic sugar for a special form of objects. Regarding monads, we had smart pointers and the like in C++ already in the 1990s. Both concepts are orthogonal to mutability.
I'm convinced that imperative programming will endure alongside functional code, because being stateful is how the real world works, and most programs have to repeatedly interact with the real world over the course of their execution.
Sure. I don't mean to say that imperative programming is going anywhere.
If you're looking for programming languages with no support for imperative programming, Excel is pretty much it. Even Haskell has robust support for sequencing actions. If it didn't, I don't think we'd be talking about it at all.
What I predict is that ideas from FP will continue to bubble up into the mainstream. Like prior inventions, they won't be presented as a thing that asks you to rework all of your algorithmic code. They will instead be polished and presented in a way that makes them work more as extensions to what you can already do.
If you squint a little bit, Haskell's do-notation is already available in mainstream languages in the form of async/await syntax. async/await is not quite as general as the original Haskell solution, but it also doesn't ask you to completely rethink the way you design algorithms.
Over the last 3 or 4 decades, our procedural and OO languages have slowly been absorbing the best ideas from "FP languages." We're getting to the stage where the very idea of a "functional language" is eroding.
>> From an OOP perspective, lambdas are just syntactic sugar for a special form of objects.
Indeed Smalltalk - a pure OOP language - had `Block` objects fifty years ago.
>> I'm convinced that imperative programming will endure alongside functional code, because being stateful is how the real world works, and most programs have to repeatedly interact with the real world over the course of their execution.
That, and also who wants to wrestle with monad transformers to make a stateful computation work when they have to fix a bug in production ASAP?
> Indeed Smalltalk - a pure OOP language - had `Block` objects fifty years ago.
Although in the original Smalltalk-80, blocks were not full closures, so it didn't support all the things you would expect to be able to do with a lambda.
"The major commercial Smalltalk implementations of the 1990’s all corrected these problems and developed various techniques for efficiently implementing blocks."
The duality between closures and objects is well known. It's hard to avoid having some construct like that, but mainstream languages shifting toward the functional perspective on it is definitely still evidence for penetration of functional ideas.
python will be the last man standing with basically no functional goodies
people will keep on trucking with their "pythonic" for loops containg appends to a list that was initialized right before, their disgust for recursion, their absence of lambdas, the lack of monadic return types or containers
Lambdas are now a requirement for any modern programming language. Monadic promises are how asynchronous programming is done. Rust is basically OCaml except with typeclasses and without a GC.
Inch by inch, ideas from FP bubble up into mainstream programming.
I predict that algebraic effects (a la Koka) are next, but it'll be a while before the industry is ready for it.