7 ms·

Why hasn't functional programming taken over yet?

37 points by 56k 11y ago

panic 11y ago
It has! Almost all major languages today let you pass functions (and closures with captured bindings) as values.
- iopq 11y ago
  That's not really what functional programming is about. Functional programming is more about avoiding state and referential transparency. Most programmers do not attempt to do this in mainstream programming languages.
  - scalatohaskell 11y ago
    avoiding global/shared state :) we are not avoiding state as per se. State if super important! That's why we care about it so much. But Im just nitpicking, sorry
    - iopq 11y ago
      I meant "hidden" state because functional programs still reason about state, but more explicitly. In a functional style you can't just call a function that relies on hidden state somewhere, you have to pass that state in! But with partial application and currying you could pass the state in at any point in the program, so all the functions on the inside are pure, while state exists on the edges.
      - hollerith 11y ago
        Well, using a state monad such as Haskell's IO monad is usually considered functional style, but the state is hidden. Moreover, any body of code in which state is passed around in explicit arguments can be transformed into code in continuation-passing style (or monadic style) in which the state is hidden -- and it's hard to argue that the code in continuation-passing style is not functional code. Whether or not the state is hidden is not one of the distinguishing features of functional programming. Referential transparency and being able to declare certain "values" to be immutable even though there are some mutable values around are. For example, if some code is referentially transparent, putting it into continuation-passing style preserves the referential transparency. BTW, some say that being able to specify the result that you want rather than needing to specify how those results are computed -- which is sometimes called "declarative programming" -- is what makes functional programming powerful, but I disagree: it is being referentially-transparent (or more precisely, more referentially-transparent that imperative code) and giving the programmer the ability to credibly assert that this or that data structure is immutable, combined with language and library support for working with immutable data structures. Another distinguishing feature of functional programming: being able to rely on (or hope for) certain compiler optimizations not available in imperative languages. (It is because of this feature that Scheme is considered by some to be a functional language.) Referential transparency might be necessary to make these optimizations tractable.
        iopq 11y ago
        IO monad doesn't hide state, it says right in the type that it's IO. Neither do other monads that "hide" state according to you, because they actually specify that they use state right in the type signature. OOP approach hides state because it uses private variables that might be modified in the body of the function. Yet there is nothing in the type signature that states that this function is not referentially transparent!
  - the_cat_kittles 11y ago
    but good programmers? yes.
  - Avshalom 11y ago
    It's what functional programming was about for the first twenty years. That and everything being an expression that returns a value.
    - coldtea 11y ago
      20? More like 40. Until 2005 or so few considered this "pure" style essential to FP.
  - turkishrevenge 11y ago
    While state/referential transparency/immutability are important (and great features), they're more associated with pure FP. Purity is not a necessary precondition for a language to be classed as "functional". I'd argue that the defining feature of FP is the treatment as functions as first class values. Everything philosophically speaking, flows from this fact.
  - eru 11y ago
    Even Python has immutable strings and numbers. Mainstream languages are slowly moving towards more and more functional concepts. The progress towards referential transparency is slow, but ongoing.
  - api 11y ago
    Isn't performance a problem? Technically you can memoize to eliminate constant recomputing of state, but that itself is overhead. Sometimes I try to use a functional style in common languages and end up backing out when it comes time to optimize.
    - eru 11y ago
      It depends on what kind of performance problems you have. Some algorithms are hard to express in pure, strict functional settings. (There's even an impossibility theorem for a few algorithms, but that theorem doesn't apply to pure, lazy languages.) That being said, the worst asymptotic slowdown is logarithmic---because you can always simulate random access memory. On a more practical side, you have constant factors to worry about, and things like caches. Look at eg Don Stewarts work for how to deal with these in a functional language. (And, in practice, there's no shame in throwing in the towel and either interfacing with other languages, or even switching to them.)
  - girvo 11y ago
    React's new stateless components are very functional in that regard, and are being adopted rapidly
sotojuan 11y ago
Not "taken over" but in many ways functional programming techniques have gotten big in front-end land, not only with JavaScript but also "real" functional languages like Elm or ClojureScript.
- the_cat_kittles 11y ago
  those are both javascript? thought you were going to say haskell or clojure...
  - sotojuan 11y ago
    Both compile to JavaScript, yes, but are their own languages used to write front-end applications. That's what I meant.
- jondubois 11y ago
  Good point, languages like JavaScript support both imperative AND declarative/functional styles. A language that lets you do both covers more use cases than a language that only does one. With a multi-paradigm language like JS, companies can choose what approach they want to use (and to what extent) and enforce it via a programming styleguide. With JavaScript, you could even run a linter over your code to strictly enforce your own FP rules. There is no doubt that FP has taken over JavaScript - All new popular frameworks including Angular, Polymer and React are declarative/functional with the exception of a few minor (but very useful) imperative concepts (e.g. these frameworks do encourage you to keep 'state' inside models). FP is awesome but 100% pure FP is just not practical - When building real-life systems, ultimately, you need to keep stack of state somewhere - Be in in the database or inside a model in your code.
  - ng12 11y ago
    This is where I think clojurescript (particularly with React) really shines. Pure functional is the default, and you have to actually do work to make things stateful. The main pitfall of almost-functional languages/frameworks is that it's all too easy to fall back on stateful programming to get things done quick-and-dirty. Clojurescript has a lot of other problems -- e.g. not really having an ecosystem outside of Lein -- but using cljs/om for the first time was like a breath of fresh air.
xyzzy4 11y ago
Because it doesn't have enough advantages to justify the added complexity.
- the_cat_kittles 11y ago
  extremely testable, easier to reason about, automatically dry, parallelizable, automatically reusable, memoizable, composable, can be analyzed with some theoretical systems, and most important- you get stuff that works better (in my experience)
  - voltagex_ 11y ago
    That's great, but how do I write a functional version of https://github.com/voltagex/junkcode/blob/master/CSharp/spotprices/spotprices/Program.cs https://github.com/voltagex/junkcode/blob/master/CSharp/spot...? All this does is pull a list of "spot instance" prices from AWS EC2, sort them and filter them. I rewrote this from a python script that became too complex. The last time I looked at Haskell, it needed ~700MB of dependencies before I could even get started. Edit: Clojure looks like a good way to start, although https://github.com/mrowe/clj-aws-ec2 https://github.com/mrowe/clj-aws-ec2 isn't really complete.
    - crusso 11y ago
      Either that or take a look at Elixir. All the 9 9's reliability and distributability of Erlang with a more Ruby-like syntax.
      - voltagex_ 11y ago
        Dunno why you were downvoted. Elixir is on my list of things to look at.
        crusso 11y ago
        I'm sure it was a misclick. ;^)
javajosh 11y ago
I've noticed that programmers tend to become more interested in functional programming over the duration of their careers. I think this is because, as a paradigm, FP solves problems that only experienced programmers realize they have. I'm not sure what the age distribution of working programmers is, but I bet the median is in the low 30's at this point, which is when you start being interested in FP in a real way. The other side of the coin is that there is tremendous "practical momentum" in software that is collected in the mass of code written in non-FP ways. Experienced programmers are usually expected to fix the symptoms, not cure the disease. Clever people might slip in some functional ideas here and there, but you're almost always better off learning the nuts-and-bolts of integrating Lucene with your Jetty app than you are learning Clojure.
- bojo 11y ago
  Very well said on both accounts.
- pmarreck 11y ago
  > as a paradigm, FP solves problems that only experienced programmers realize they have This is exactly what I've been saying... and it's the essence of the "FP non-adoption problem." I came to FP because I became frustrated with classes of bugs that appeared over and over again in OO (Ruby, in my case) but which seem to plague FP code much less. In essence, I came to reduce labor/increase productivity; it's "laziness/impatience/hubris" all over again. One indicator that I was "naturally" coming to FP is that I noticed I was writing Ruby code in a very functional style. I say "naturally" because 1) it made it easier to test 2) it reduced spaghetti code and dependencies 3) it made it more modular 4) it reduced side effects and bug generation. And all of these worked together to just make better code, period. Then I came across Elixir (http://elixir-lang.org/ http://elixir-lang.org/) and lo and behold, now I can't wait to find work in this shiny new FP language. If most people in a career came to prefer a certain paradigm after 10-20 years in that career, shouldn't everyone in that career be taking a serious look at it?
- the_cat_kittles 11y ago
  beautifully put. the first part is a specific case of a more general pattern i see in myself and others, where an older more experienced person does something in a way i think is silly, then i see the wisdom in it later. i think tech is, in general, ridiculously dismissive of experience. not too controversial an opinion i know, but i think it bears repeating.
jonsmit 11y ago
Because most people are not smart. And because customers will pay more for software with bugs in it.
- zcdziura 11y ago
  Careful, you may cut yourself on all that edge.
- jondubois 11y ago
  At least the software will be ready on time.
coldtea 11y ago
>Stateless programs; No side effects Which is not all it's touted up to be. >Concurrency; Plays extremely nice with the rising multi-core technology Nice, but not that nice. Don't expect any significant speedup for the most common kinds of programs. >Programs are usually shorter and in some cases easier to read For some people they are harder to read. As for shorter, Python can be pretty terse too, as can lots of other languages. >Productivity goes up (example: Erlang) Anecdotal. In the real world, most systems in production (including at NASA and the most critical environments) are made with imperative/oo/etc programming, which must count for something. For every WhatsApp there are 10,000 stories of such programs. >Imperative programming is a very old paradigm (as far as I know) Functional programming is 5+ decades old too. And parts of math are even older, but we're still keeping them... >and possibly not suitable for the 21st century Citation needed.
- im_down_w_otp 11y ago
  There are not 10,000 other WhatsApps, FWIW. By any useful measure. User base, concurrent active sessions, both of those relative to size of dev team and/or infrastructure footprint, acquisition price, user growth rate, etc. Though WhatsApp's success was predicated on dogged adherence to core principles of understanding their problem extremely well, selecting the right tools to solve that problem, and do as much as possible with as little as possible. Erlang was just one part of that. Choosing FreeBSD, not hiring craploads of engineers just for the sake of hiring, keeping as little intermediate state as possible, etc. we're all contributors to their success story. But if you have a high-concurrency, small-packet, low-latency, supreme-uptime message processing shaped problem it's pretty dang hard to do better than Erlang as a foundational choice.
  - coldtea 11y ago
    >There are not 10,000 other WhatsApps, FWIW No 10,000 other WhatsApps. 10,000 success stories of programs doing what they need to do with a small team behind them and reliability. It's about the technical/project success aspects, not about the monetary side of the equation -- not even about user count. After all Yahoo (back in the day) and Facebook had a much higher user count while being written in PHP.
a3n 11y ago
Possibly because the way we learn math, and the math that most of us learn, is taught procedurally. It's the mindset that many of us grow up with. I'm not in the valley, and I can't recall ever seeing an ad for functional anything, not even Erlang. I'm sure there's some around, around here, but not enough that I'll see it when I'm casually looking.
zelcon5 11y ago
Because programming is primarily a business and it's cheaper to hire dumb programmers for whom functional programming is too difficult.
pacala 11y ago
Between Excel and SQL, I'd say collection-oriented programming has pretty much taken over the world.
- pklausler 11y ago
  One could make a case for a spreadsheet being a limited kind of pure functional programming language.
  - dang 11y ago
    Not pure, because you have state at the top level.
    - pklausler 11y ago
      Sure, but it isn't being modified by the expressions in the cells.
      - dang 11y ago
        True, and that's a good way of putting it.
DrScump 11y ago
Why does this point to the Wayback archive of the page instead of the native page? http://stackoverflow.com/questions/2835801/why-hasnt-functional-programming-taken-over-yet/2835936 http://stackoverflow.com/questions/2835801/why-hasnt-functio...
- iconjack 11y ago
  I was wondering that myself. Figured it must be because SO deleted the original, but like you, I checked and there it was, not even closed.

37 points by 56k 11y ago

panic 11y ago

It has! Almost all major languages today let you pass functions (and closures with captured bindings) as values.

iopq 11y ago
That's not really what functional programming is about. Functional programming is more about avoiding state and referential transparency. Most programmers do not attempt to do this in mainstream programming languages.
- scalatohaskell 11y ago
  avoiding global/shared state :) we are not avoiding state as per se. State if super important! That's why we care about it so much. But Im just nitpicking, sorry
  - iopq 11y ago
    I meant "hidden" state because functional programs still reason about state, but more explicitly. In a functional style you can't just call a function that relies on hidden state somewhere, you have to pass that state in! But with partial application and currying you could pass the state in at any point in the program, so all the functions on the inside are pure, while state exists on the edges.
    - hollerith 11y ago
      Well, using a state monad such as Haskell's IO monad is usually considered functional style, but the state is hidden. Moreover, any body of code in which state is passed around in explicit arguments can be transformed into code in continuation-passing style (or monadic style) in which the state is hidden -- and it's hard to argue that the code in continuation-passing style is not functional code. Whether or not the state is hidden is not one of the distinguishing features of functional programming. Referential transparency and being able to declare certain "values" to be immutable even though there are some mutable values around are. For example, if some code is referentially transparent, putting it into continuation-passing style preserves the referential transparency. BTW, some say that being able to specify the result that you want rather than needing to specify how those results are computed -- which is sometimes called "declarative programming" -- is what makes functional programming powerful, but I disagree: it is being referentially-transparent (or more precisely, more referentially-transparent that imperative code) and giving the programmer the ability to credibly assert that this or that data structure is immutable, combined with language and library support for working with immutable data structures. Another distinguishing feature of functional programming: being able to rely on (or hope for) certain compiler optimizations not available in imperative languages. (It is because of this feature that Scheme is considered by some to be a functional language.) Referential transparency might be necessary to make these optimizations tractable.
      - iopq 11y ago
        IO monad doesn't hide state, it says right in the type that it's IO. Neither do other monads that "hide" state according to you, because they actually specify that they use state right in the type signature. OOP approach hides state because it uses private variables that might be modified in the body of the function. Yet there is nothing in the type signature that states that this function is not referentially transparent!
- the_cat_kittles 11y ago
  but good programmers? yes.
- Avshalom 11y ago
  It's what functional programming was about for the first twenty years. That and everything being an expression that returns a value.
  - coldtea 11y ago
    20? More like 40. Until 2005 or so few considered this "pure" style essential to FP.
- turkishrevenge 11y ago
  While state/referential transparency/immutability are important (and great features), they're more associated with pure FP. Purity is not a necessary precondition for a language to be classed as "functional". I'd argue that the defining feature of FP is the treatment as functions as first class values. Everything philosophically speaking, flows from this fact.
- eru 11y ago
  Even Python has immutable strings and numbers. Mainstream languages are slowly moving towards more and more functional concepts. The progress towards referential transparency is slow, but ongoing.
- api 11y ago
  Isn't performance a problem? Technically you can memoize to eliminate constant recomputing of state, but that itself is overhead. Sometimes I try to use a functional style in common languages and end up backing out when it comes time to optimize.
  - eru 11y ago
    It depends on what kind of performance problems you have. Some algorithms are hard to express in pure, strict functional settings. (There's even an impossibility theorem for a few algorithms, but that theorem doesn't apply to pure, lazy languages.) That being said, the worst asymptotic slowdown is logarithmic---because you can always simulate random access memory. On a more practical side, you have constant factors to worry about, and things like caches. Look at eg Don Stewarts work for how to deal with these in a functional language. (And, in practice, there's no shame in throwing in the towel and either interfacing with other languages, or even switching to them.)
- girvo 11y ago
  React's new stateless components are very functional in that regard, and are being adopted rapidly

sotojuan 11y ago

Not "taken over" but in many ways functional programming techniques have gotten big in front-end land, not only with JavaScript but also "real" functional languages like Elm or ClojureScript.

the_cat_kittles 11y ago
those are both javascript? thought you were going to say haskell or clojure...
- sotojuan 11y ago
  Both compile to JavaScript, yes, but are their own languages used to write front-end applications. That's what I meant.
jondubois 11y ago
Good point, languages like JavaScript support both imperative AND declarative/functional styles. A language that lets you do both covers more use cases than a language that only does one. With a multi-paradigm language like JS, companies can choose what approach they want to use (and to what extent) and enforce it via a programming styleguide. With JavaScript, you could even run a linter over your code to strictly enforce your own FP rules. There is no doubt that FP has taken over JavaScript - All new popular frameworks including Angular, Polymer and React are declarative/functional with the exception of a few minor (but very useful) imperative concepts (e.g. these frameworks do encourage you to keep 'state' inside models). FP is awesome but 100% pure FP is just not practical - When building real-life systems, ultimately, you need to keep stack of state somewhere - Be in in the database or inside a model in your code.
- ng12 11y ago
  This is where I think clojurescript (particularly with React) really shines. Pure functional is the default, and you have to actually do work to make things stateful. The main pitfall of almost-functional languages/frameworks is that it's all too easy to fall back on stateful programming to get things done quick-and-dirty. Clojurescript has a lot of other problems -- e.g. not really having an ecosystem outside of Lein -- but using cljs/om for the first time was like a breath of fresh air.

xyzzy4 11y ago

Because it doesn't have enough advantages to justify the added complexity.

the_cat_kittles 11y ago
extremely testable, easier to reason about, automatically dry, parallelizable, automatically reusable, memoizable, composable, can be analyzed with some theoretical systems, and most important- you get stuff that works better (in my experience)
- voltagex_ 11y ago
  That's great, but how do I write a functional version of https://github.com/voltagex/junkcode/blob/master/CSharp/spotprices/spotprices/Program.cs https://github.com/voltagex/junkcode/blob/master/CSharp/spot...? All this does is pull a list of "spot instance" prices from AWS EC2, sort them and filter them. I rewrote this from a python script that became too complex. The last time I looked at Haskell, it needed ~700MB of dependencies before I could even get started. Edit: Clojure looks like a good way to start, although https://github.com/mrowe/clj-aws-ec2 https://github.com/mrowe/clj-aws-ec2 isn't really complete.
  - crusso 11y ago
    Either that or take a look at Elixir. All the 9 9's reliability and distributability of Erlang with a more Ruby-like syntax.
    - voltagex_ 11y ago
      Dunno why you were downvoted. Elixir is on my list of things to look at.
      - crusso 11y ago
        I'm sure it was a misclick. ;^)

javajosh 11y ago

I've noticed that programmers tend to become more interested in functional programming over the duration of their careers. I think this is because, as a paradigm, FP solves problems that only experienced programmers realize they have. I'm not sure what the age distribution of working programmers is, but I bet the median is in the low 30's at this point, which is when you start being interested in FP in a real way. The other side of the coin is that there is tremendous "practical momentum" in software that is collected in the mass of code written in non-FP ways. Experienced programmers are usually expected to fix the symptoms, not cure the disease. Clever people might slip in some functional ideas here and there, but you're almost always better off learning the nuts-and-bolts of integrating Lucene with your Jetty app than you are learning Clojure.

bojo 11y ago
Very well said on both accounts.
pmarreck 11y ago
> as a paradigm, FP solves problems that only experienced programmers realize they have This is exactly what I've been saying... and it's the essence of the "FP non-adoption problem." I came to FP because I became frustrated with classes of bugs that appeared over and over again in OO (Ruby, in my case) but which seem to plague FP code much less. In essence, I came to reduce labor/increase productivity; it's "laziness/impatience/hubris" all over again. One indicator that I was "naturally" coming to FP is that I noticed I was writing Ruby code in a very functional style. I say "naturally" because 1) it made it easier to test 2) it reduced spaghetti code and dependencies 3) it made it more modular 4) it reduced side effects and bug generation. And all of these worked together to just make better code, period. Then I came across Elixir (http://elixir-lang.org/ http://elixir-lang.org/) and lo and behold, now I can't wait to find work in this shiny new FP language. If most people in a career came to prefer a certain paradigm after 10-20 years in that career, shouldn't everyone in that career be taking a serious look at it?
the_cat_kittles 11y ago
beautifully put. the first part is a specific case of a more general pattern i see in myself and others, where an older more experienced person does something in a way i think is silly, then i see the wisdom in it later. i think tech is, in general, ridiculously dismissive of experience. not too controversial an opinion i know, but i think it bears repeating.

jonsmit 11y ago

Because most people are not smart. And because customers will pay more for software with bugs in it.

zcdziura 11y ago
Careful, you may cut yourself on all that edge.
jondubois 11y ago
At least the software will be ready on time.

coldtea 11y ago

>Stateless programs; No side effects Which is not all it's touted up to be. >Concurrency; Plays extremely nice with the rising multi-core technology Nice, but not that nice. Don't expect any significant speedup for the most common kinds of programs. >Programs are usually shorter and in some cases easier to read For some people they are harder to read. As for shorter, Python can be pretty terse too, as can lots of other languages. >Productivity goes up (example: Erlang) Anecdotal. In the real world, most systems in production (including at NASA and the most critical environments) are made with imperative/oo/etc programming, which must count for something. For every WhatsApp there are 10,000 stories of such programs. >Imperative programming is a very old paradigm (as far as I know) Functional programming is 5+ decades old too. And parts of math are even older, but we're still keeping them... >and possibly not suitable for the 21st century Citation needed.

im_down_w_otp 11y ago
There are not 10,000 other WhatsApps, FWIW. By any useful measure. User base, concurrent active sessions, both of those relative to size of dev team and/or infrastructure footprint, acquisition price, user growth rate, etc. Though WhatsApp's success was predicated on dogged adherence to core principles of understanding their problem extremely well, selecting the right tools to solve that problem, and do as much as possible with as little as possible. Erlang was just one part of that. Choosing FreeBSD, not hiring craploads of engineers just for the sake of hiring, keeping as little intermediate state as possible, etc. we're all contributors to their success story. But if you have a high-concurrency, small-packet, low-latency, supreme-uptime message processing shaped problem it's pretty dang hard to do better than Erlang as a foundational choice.
- coldtea 11y ago
  >There are not 10,000 other WhatsApps, FWIW No 10,000 other WhatsApps. 10,000 success stories of programs doing what they need to do with a small team behind them and reliability. It's about the technical/project success aspects, not about the monetary side of the equation -- not even about user count. After all Yahoo (back in the day) and Facebook had a much higher user count while being written in PHP.

a3n 11y ago

Possibly because the way we learn math, and the math that most of us learn, is taught procedurally. It's the mindset that many of us grow up with. I'm not in the valley, and I can't recall ever seeing an ad for functional anything, not even Erlang. I'm sure there's some around, around here, but not enough that I'll see it when I'm casually looking.

zelcon5 11y ago

Because programming is primarily a business and it's cheaper to hire dumb programmers for whom functional programming is too difficult.

pacala 11y ago

Between Excel and SQL, I'd say collection-oriented programming has pretty much taken over the world.

pklausler 11y ago
One could make a case for a spreadsheet being a limited kind of pure functional programming language.
- dang 11y ago
  Not pure, because you have state at the top level.
  - pklausler 11y ago
    Sure, but it isn't being modified by the expressions in the cells.
    - dang 11y ago
      True, and that's a good way of putting it.

DrScump 11y ago

Why does this point to the Wayback archive of the page instead of the native page? http://stackoverflow.com/questions/2835801/why-hasnt-functional-programming-taken-over-yet/2835936 http://stackoverflow.com/questions/2835801/why-hasnt-functio...

iconjack 11y ago
I was wondering that myself. Figured it must be because SO deleted the original, but like you, I checked and there it was, not even closed.