I think in the end step by step functional programming will be widely adopted. Concepts that have a strong theory behind them tend to last longer. Similar to how relational databases and SQL are still the gold standard today.
> Concepts that have a strong theory behind them tend to last longer.
The programming paradigms (functional, imperative, declarative) as implemented generally don't have strong theories behind them. We have no sharp line to detect when a language sits in any of those categories for any major language apart from SQL. One can write something that is recognised as functional in an imperative language for example. And even the best example of purity, SQL, in practice needs to be hosted in an imperative or functional environment to get useful results. The declarative part of the language isn't competent at getting complex performance-friendly results.
One of the interesting things about being a member of the functional programming community is I genuinely can't tell what the claim to fame of the community actually is beyond a sort of club-like atmosphere where people don't like mutability. Are we claiming that C++ programmers don't know how to write pure functions? I hope not, they clearly know. Many are good at it.
I see this misconception a lot. Functional programming has nothing to do with mutability or immutability. Just like product types (or associative arrays) don't make for object oriented programming, the paradigm is about the patterns you use and the total structure of the program. In the case of functional programming, it's that your entire program is built around function composition and folds. This changes how you build your program on a fundamental level.
Additionally, functional programming does have a strong theory behind it. That of the lambda calculus. Everything is formalization and constructions built on top of that. We don't have a "hard line" to detect if a language is "functional" because it's not a language paradigm, but a property of the code itself. Grammar is orthogonal to this stuff. You can, however, make a pretty good guess by looking at the standard library of a language. There is no ambiguity that Idris or Haskell are a languages designed for functional programming, for example.
I think this stems from a problem that there are a lot of programmers, who through no fault of their own, have engaged with tools for functional programming, but skipped building things using the alien and weird stuff so in the end there's no actual learning of functional programming itself. Every new programming paradigm is a shift of your core perspective, they require you to relearn programming from the ground up. It shouldn't feel like "this is just ABC with XYZ", you are only truly beginning to learn when you are put back into your shoes as a middle schooler unlocking the power of nested conditionals. If you don't get that feeling, you're just learning a different language and not a programming paradigm.
> And even the best example of purity, SQL
Purity is not a claim of functional programming. Also SQL is not anywhere close to being a functional language, it's not only a non-programming language, but even if it were (and it can be with extensions) its paradigm is far more in line with logic programming.
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.
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
That seems improbable. Pure functional languages are very unpopular according to TIOBE. In particular, interest in Haskell seems to be in decline. Functional features are mostly just an add-on to programming languages with mutable state. By far the most popular language, Python, doesn't even have static typing.
I know powerful typing features are very important for Haskell in particular, but is static typing considered a functional feature more broadly? Most lisps don't have static typing as far as I know. Clojure was one of the main functional languages that actually saw industry use for a while, and it is dynamically typed.
That's already been happening for quite some time. Mainstream programming has done little else in recent years than converge toward functional programming.
Also, they wrote "functional," not "purely functional."
By the way, from a formal perspective, imperative programming is an extension of purely functional programming.
Haskell is suitable for, and designed for, bleeding edge experiments, not for practical usage. Its low popularity says very little about the "market penetration" of better engineered functional languages.
> Similar to how relational databases and SQL are still the gold standard today.
...except they aren't. The world is gradually slipping towards nosql databases and stepping away from normalized data stores, to the point where tried and true RDBMS are shoehorning support for storing and querying JSON documents.
All flagship database services from major cloud providers are nosql databases.
Perhaps you're confusing pervasiveness with representing gold standard. Yes, RDBMS are pervasive, but so are non-compliance with the standard and vendor-specific constructs. The biggest factor was not what was the theoretical background behind each implementation but ease of use and ease of adoption. SQLite is an outstanding database not because of its compliance with SQL standards and adherence to theoretical purity, but because it's FLOSS and trivial to setup and use.
I expect the same factors to be relevant in adoption of functional programming. This stuff exists for decades on end but mass adoption was between negligible to irrelevant. What started to drive adoption was the inception of modules and components that solved real-world problems and helped developers do what they wanted to do with less effort. In JavaScript the use of map, filter and reduce is not driven by any new-founded passion for function programming but because it's right there and it's concise and simple and readable and capable. In C#, linq is gaining traction for the same reasons but is largely kept back by performance issues.
The key aspect is pragmatism, and theoretical elegance is by far a mere nice-to-have.
> ..except they aren't. The world is gradually slipping towards nosql databases and stepping away from normalized data stores
The 2010s called and want their database paradigm back.
NoSQL is definitely not the zeitgeist today. Graph DBs, KV stores, document DBs, and OLTP DBs are what is popular today- I would say that the two shifts I see in the 2020s is the rise of cache-as-database (eg redis) and an “all of the above” mentality rather than one-size-fits-all.
> The world is gradually slipping towards nosql databases
My observation has been that this pendulum is swinging back the other direction. You're correct that some NoSQL-isms found their way into RDBMS, but at least in the circles in which I travel, people are by and large heading back to RDBMS stores.
roenxi|5 months ago
The programming paradigms (functional, imperative, declarative) as implemented generally don't have strong theories behind them. We have no sharp line to detect when a language sits in any of those categories for any major language apart from SQL. One can write something that is recognised as functional in an imperative language for example. And even the best example of purity, SQL, in practice needs to be hosted in an imperative or functional environment to get useful results. The declarative part of the language isn't competent at getting complex performance-friendly results.
One of the interesting things about being a member of the functional programming community is I genuinely can't tell what the claim to fame of the community actually is beyond a sort of club-like atmosphere where people don't like mutability. Are we claiming that C++ programmers don't know how to write pure functions? I hope not, they clearly know. Many are good at it.
ux266478|5 months ago
Additionally, functional programming does have a strong theory behind it. That of the lambda calculus. Everything is formalization and constructions built on top of that. We don't have a "hard line" to detect if a language is "functional" because it's not a language paradigm, but a property of the code itself. Grammar is orthogonal to this stuff. You can, however, make a pretty good guess by looking at the standard library of a language. There is no ambiguity that Idris or Haskell are a languages designed for functional programming, for example.
I think this stems from a problem that there are a lot of programmers, who through no fault of their own, have engaged with tools for functional programming, but skipped building things using the alien and weird stuff so in the end there's no actual learning of functional programming itself. Every new programming paradigm is a shift of your core perspective, they require you to relearn programming from the ground up. It shouldn't feel like "this is just ABC with XYZ", you are only truly beginning to learn when you are put back into your shoes as a middle schooler unlocking the power of nested conditionals. If you don't get that feeling, you're just learning a different language and not a programming paradigm.
> And even the best example of purity, SQL
Purity is not a claim of functional programming. Also SQL is not anywhere close to being a functional language, it's not only a non-programming language, but even if it were (and it can be with extensions) its paradigm is far more in line with logic programming.
implicit|5 months ago
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.
layer8|5 months 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.
VeejayRampay|5 months ago
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
cubefox|5 months ago
Fraterkes|5 months ago
ahf8Aithaex7Nai|5 months ago
Also, they wrote "functional," not "purely functional."
By the way, from a formal perspective, imperative programming is an extension of purely functional programming.
HelloNurse|5 months ago
bheadmaster|5 months ago
Arguably, Python is statically typed - it's just that it only has one type: object.
unknown|5 months ago
[deleted]
motorest|5 months ago
...except they aren't. The world is gradually slipping towards nosql databases and stepping away from normalized data stores, to the point where tried and true RDBMS are shoehorning support for storing and querying JSON documents.
All flagship database services from major cloud providers are nosql databases.
Perhaps you're confusing pervasiveness with representing gold standard. Yes, RDBMS are pervasive, but so are non-compliance with the standard and vendor-specific constructs. The biggest factor was not what was the theoretical background behind each implementation but ease of use and ease of adoption. SQLite is an outstanding database not because of its compliance with SQL standards and adherence to theoretical purity, but because it's FLOSS and trivial to setup and use.
I expect the same factors to be relevant in adoption of functional programming. This stuff exists for decades on end but mass adoption was between negligible to irrelevant. What started to drive adoption was the inception of modules and components that solved real-world problems and helped developers do what they wanted to do with less effort. In JavaScript the use of map, filter and reduce is not driven by any new-founded passion for function programming but because it's right there and it's concise and simple and readable and capable. In C#, linq is gaining traction for the same reasons but is largely kept back by performance issues.
The key aspect is pragmatism, and theoretical elegance is by far a mere nice-to-have.
efitz|5 months ago
The 2010s called and want their database paradigm back.
NoSQL is definitely not the zeitgeist today. Graph DBs, KV stores, document DBs, and OLTP DBs are what is popular today- I would say that the two shifts I see in the 2020s is the rise of cache-as-database (eg redis) and an “all of the above” mentality rather than one-size-fits-all.
jghn|5 months ago
My observation has been that this pendulum is swinging back the other direction. You're correct that some NoSQL-isms found their way into RDBMS, but at least in the circles in which I travel, people are by and large heading back to RDBMS stores.
taffer|5 months ago
That was in 2012. Nowadays, NoSQL companies are shoehorning SQL into their products.
> All flagship database services from major cloud providers are nosql databases.
AWS Aurora, Google's Spanner and Big Query and Snowflake are all SQL DBs.