19 ms·

Functional thinking: Why functional programming is on the rise

187 points by Adrock 14y ago

discreteevent 14y ago
The thing is that any imperative programmers who have composed SQL subqueries have have been doing this kind of thinking for years whether they realise it or not. The only substantial difference is that the data is in the process' memory as maps and lists as opposed to relational tables in the db. You end up with exactly the same kind of patterns of composition in the code.
- pestaa 14y ago
  Completely disagree. Composing SQL queries even on multiple levels (as in subqueries) might involve a way of thinking that remotely resembles to functional programming, it is way too simplistic for comparison with real world functional programs, at least in my experience. I know I grasped SQL really quickly, and still get puzzled by Haskell after 6 months of trying.
  - fusiongyro 14y ago
    I disagree with both of you. I think you're underestimating what can be done in SQL--recursive queries and correlated subqueries are not part of most competent developers' "standard toolkit"--but I think you're illustrating the problem with the OP's point, which is that most competent developers get through joins and outer joins (usually inheriting a lot of weird mythology like "joins are expensive") and can select/project and that's about where the skills end. So while I disagree with you in principle, in practice most people's SQL skills are inadequate even for an analogy to functional programming. I would not say that the thought process I use when writing SQL queries is "more like" my thought process when doing functional programming than imperative programming. In truth, the similarity is all in what isn't present: I'm not deeply worried about what the machine is going to do with my request and how it's going to process it. I remain cognizant of what's "really happening" to the extent that I want to avoid obvious performance pitfalls, but it doesn't become the overriding obsession that it is with procedural programming. With declarative programming I worry much less about whether the result is correct, and this is the primary benefit to me.
  - tel 14y ago
    Haskell isn't just FP. It has a lot of other stuff, orthogonal stuff---most notably the HM type system---which really helps to take advantage of "pure" FP. Getting bogged down in Haskell doesn't mean that SQL doesn't have a lot of great compositional aspects that are inherited from its "more functional" nature.
  - jeffdavis 14y ago
    "[SQL] is way too simplistic for comparison with real world functional programs" Another way of interpreting that is that the ideas behind SQL are so powerful that it's able to be one of the most successful programming languages of all time without all the bells and whistles of a language like haskell. It's so successful that it can get by with horrid syntax, a ton of special cases built in, and the mess of SQL NULL semantics. Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful. I don't necessarily disagree with you, depending on what you mean by "real world" programs. I just think that if there is already an area where the concepts are useful (whether you call that a "real world program" or not), it makes a lot of sense to keep trying to build from that. Trying to convince someone to learn haskell to build a website when they already know and like ruby is an uphill battle.
    - martinced 14y ago
      "Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful." But some do. For example Rich Hickey used Clojure (which both users and encourages FP but still allows to bend the rules when needed) to create Datomic. It's a DB but it's CRA instead of CRUD. Making it just so much easier to reason about. The DB is ever-growing and any query becomes "query at time t". And later on, when you query again "query at time t", you CANNOT get a different answer. Typical CRUD DBs are place-oriented mutability mess and, honestly, reading about MySQL fanbois vs PostgreSQL fanbois arguing about which one is the best looks, from a CRA point of view, as a blind man arguing with a one-eyed about who has the best eye vision. Datomic is ACID, has infinite read scalability and can use SQL DBs (and many others) as their persistence stores. It is as Real-World as one can get since that Rich Hickey as seen exactly what we're all witnessing daily in the real-IT-world: a gigantic ball of mutability mess. To me the revolution is on and there's no going back for those who switched. From there it's just a matter of time.
      - jeffdavis 14y ago
        Thank you. I knew that Datomic existed, and some of the basic things you pointed out here, but I'll take a closer look. It seems like you really think it has a lot of promise. That being said, I don't think CRA is a panacea. Databases will always have a "read, decide what to do, write" pattern (because that is what happens in the real world, and databases model the real world). If the read happens at time T, and the write happens at time T+100; then you could have a race condition if something happens at time T+50. Postgres can detect such race conditions by using true serializability (based on a technique called Serializable Snapshot Isolation[1]). It gets tricky to apply the same technique for temporal databases, though I believe it's possible. Do you happen to know what techniques Datomic offers users to help avoid/detect/resolve race conditions? Don't get me wrong. I think it's a very useful direction to go in. I've done a lot of work on temporal features in postgres. I'm also aware of some of the limitations, however. You still need some kind of coordination and something resembling locks or a conflict detector. (By the way, please avoid derogatory comments about people who make different technology choices than you do. An argument could be made that postgres is CRA. And even if not, CRA versus CRUD is a small part of what is actually important to users; many of whom face a different set of trade-offs than you do.) [1] http://drkp.net/papers/ssi-vldb12.pdf http://drkp.net/papers/ssi-vldb12.pdf
- tikhonj 14y ago
  This general idea is well illustrated by LINQ: it essentially garbs basic functional programming into SQL's garments and passes it off to C# programmers, who happily use it for a whole bunch of different things. Some of these things (like RX) are really nothing like normal SQL at all.
- agumonkey 14y ago
  And it's probably a matter of ecosystem too. Outside databases you end up depending on stateful libs/components so you're kinda forced to go with the flow, too much inertia.
- jeffdavis 14y ago
  In many ways, SQL is the case that proves how important and practical some functional language ideas are. SQL is, by many measures, one of the most successful programming languages of all time.
Chris_Newton 14y ago
Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation; - a common set of basic data structures (set, sequence, dictionary, tree, etc.) and generalised operations for manipulating and combining them (map, filter, reduce, intersection, union, zip, convert a tree to a sequence breadth-first or depth-first, etc.); - a more declarative programming style, writing specifications rather than instructions; - a programming style that emphasizes the data flow more than the control flow. I see these as distinct, though certainly not independent, concepts. I’m not sure whether functional programming itself is really on the rise, not to the extent of becoming a common approach in the mainstream programming world any time soon. I don’t think we’ve figured out how to cope with effectful systems and the real world having a time dimension very well yet. (I don’t think we’ve figured it out very well in imperative programming yet either, but the weakness is less damaging there because there is an implicit time dimension whether you want it or not.)
- rayiner 14y ago
  What is your third point if not functional programming?
  - ufo 14y ago
    declarative vs imperative is kind of a subjective thing but functional programming is not the only way to do declarative programming (logic programming and SQL are two examples that come to mind)
  - Chris_Newton 14y ago
    Functional programming, by definition, is expressing a program as a function to be evaluated. That implies that, at least to some extent, all functional programs are written in a declarative style. However, we use a declarative style for other kinds of language as well: Prolog, SQL and CSS are three very different examples, none of which is a functional programming language similar to ML or Haskell or Clojure.
rdtsc 14y ago
I think a big one is concurrency. Highly concurrent application will become more popular. Functional programming via immutable data structures is one sane way to manage that. Clojure is doing it. Erlang has been doing it for years. Haskell has that. Fear of large, mutable state is well founded. What else I think is healthy is adoption of these patterns. It is possibly to be diligent and try to apply some of the idea using other languages (C++, Python etc). It is just a different way of thinking and structuring code.
spikels 14y ago
Why is functional programming on the rise? I have heard several times that the big payoff with function programming comes from parallel processing. Because functions typically have no side effects they can operate on a set of inputs in parallel without modification. This is important because future increases in processing power are expected to come primarily from more cores rather than higher clock speeds as in the past. Is this correct? The author seems to focus on other real but lesser benefits.
- PeterisP 14y ago
  I've done a bunch of both 'classic' and functional programming, and for me the biggest difference is a switch in code-writing mindset. In imperative languages, generally, I tell the computer what and how it should do - no matter if it's assembly, C, Java or [most of] Ruby. In FP languages (Haskell or Scala, haven't worked with Lisps), I generally tell the computer what needs to be computed and expect it to figure out how to do it - what order of execution, what grouping of data, what to cache. If you compare Java code and Scala code for the same algorithm, using the same JVM API - then the main nonsyntactic difference between them will be a pile of missing Java lines detailing the order of processing steps and loops, which probably weren't essential to the algorithm - when writing the Java code I could've written it in opposite way with the same result. What I lose in FP is the ability to easily explicitly do time/space tradeoffs. Sometimes I need to control that, and then it's a bit trickier. However, it can be fixed with minor refinement of language and libraries - the original article cites a great example on how memoization should be implemented in all great languages. Parallelism currently is just a nice bonus - say, I lose 3x performance by not detailing a great execution path manually in C++; but I gain 3x performance since most of the code is trivially parallelizable to run on 4 cores. For example, in Haskell it's often literally a one-line change, while in Java it'd be a pain in the butt to make everything safely threaded.
  - mikecsh 14y ago
    This is one of the clearest and most concise explanations on the benefits of FP that I have seen. Thanks!
  - 14y ago
stmartin 14y ago
YAWN
ilaksh 14y ago
Highly recommend LiveScript if you like CoffeeScript or JavaScript or functional programming. http://livescript.net http://livescript.net
- fourstar 14y ago
  Any reason why they ripped the original name for Javascript off? I totally thought you were joking until I went to the site and noticed it's a current project.
  - GeZe 14y ago
    The name is a joke, the project is not. "LiveScript was one of the original names for JavaScript, so it seemed fitting. It's an inside joke for those who know JavaScript well." (from the site) LiveScript hasn't been used as a name for JavaScript in almost two decades.
    - fourstar 14y ago
      Thanks for explaining.
- cpeterso 14y ago
  LiveScript was the original name for JavaScript in Netscape Navigator 2.0's beta releases.
neur0 14y ago
Quite off-topic, but the underscores for the variable names in the first code snippet are totally irritatingly useless and anachronistic in the most ugly looking way.
- efnx 14y ago
  They mark the private variables so you don't have to remember which ones are private when you read further down the page. That's pretty common place and good style, IMO. What makes you think they're anachronistic?
taeric 14y ago
Doesn't this just bend back to Moore's law? Sure, there are more "efficient" data structures for use in functional styles now than there were in the past, but they all seem to treat memory as if it is free. Basically, now that we have such impressive computing resources, we can start thinking of the programs we are writing in terms of the abstractions themselves, and less in terms of the abstraction that is the computer. (That is, many of us are lucky enough to not worry about caching strategies, threading concerns, etc.) The entire debate about immutable structures is amusing when you consider old resources where there is not spare room for a new copy of a string just from a different starting point. (Referring to the new Java behavior of .substring)
slyv 14y ago
I have been meaning to dig deeper into functional programming, specifically Clojure, but as a newbie to functional programming, I am finding it hard to find a detailed tutorial that I can start to get started with the concepts and programming used in Clojure. Would anyone have any recommendations for a guide?
- billsix 14y ago
  pg's "ANSI Common Lisp" and "On Lisp" are both great. Your question was about Clojure, but the material in those books is easily transferable to other lisp dialects.
- espeed 14y ago
  Programming Clojure by Stuart Halloway is the clearest introduction to Clojure I've read: http://www.amazon.com/Programming-Clojure-Stuart-Halloway/ http://www.amazon.com/Programming-Clojure-Stuart-Halloway/
- pearle 14y ago
  This site is a bit old now (not sure if it's kept up to date) but I found it helpful when I first started playing with Clojure several years ago (wow...that long already)? http://java.ociweb.com/mark/clojure/article.html http://java.ociweb.com/mark/clojure/article.html
justin_vanw 14y ago
They are assuming that functional programming is on the rise. With the exception of Clojure (which is more popular by virtue of being new), I don't know of any functional language that are in any measurable way more popular (I assume that is what they mean by on the rise) than it has been in the last 10 years. In fact, the only application I use that is built using functional programming is Xmonad. Also, none of the top languages on the TIOBE survey are purely functional, although one in the top 20, 'lisp' with .9% and falling, does promote a functional style. People expound the virtues of functional programming year after year, and then go off and get a bunch done with Python. Steve Yegge said it best: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html http://steve-yegge.blogspot.com/2010/12/haskell-researchers-... http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
- batgaijin 14y ago
  Hypothetically you are a big company able to deliver increasingly complicated software that far outperforms the competition because of functional programming. Would you want to correct a remark like this by IBM? Why on earth would you want to educated pointy-haired individuals when you can be another vapid supporter of the six-sigma model?
goggles99 14y ago
The majority of people Are Lazy - This is why java and other languages abstracted further than C/C++ became so popular. Functional programming is more natural and comes with a smaller learning curve. It does not require the same amount of discipline to become proficient - nor the conceptual, analytical problem solver skills to master. But that is just the language, what about the design of an large scale application suite? So people with less analytic abilities and problem solving skills, (I think of those who HAD TO choose Humanities and arts majors here?) Can actually pick it up. This can be looked at as good or bad, in the long run it is probably good overall because the understanding of hardware and memory become less important as processors, memory, storage, and bandwidth become cheaper There will always be the geeks who still understand everything and can design and architect the software for the developers to code. One downside may be that those with the analytic/problem solving minds will lose their art in a sense and lose the very thing that keeps their minds sharp. Another thing worth mentioning is, there is going to be a lot of changes for developers. Wages will go down as it gets easier to learn how to program - thus more programmers flood the market (supply and demand), also their will be a separation of Architects and code monkeys - the latter being the Humanities graduate type. To sum up - This will "Dumb Down" your average developer and create a clearly defined separation between developers and designers/architects.

187 points by Adrock 14y ago

The thing is that any imperative programmers who have composed SQL subqueries have have been doing this kind of thinking for years whether they realise it or not. The only substantial difference is that the data is in the process' memory as maps and lists as opposed to relational tables in the db. You end up with exactly the same kind of patterns of composition in the code.

pestaa 14y ago
Completely disagree. Composing SQL queries even on multiple levels (as in subqueries) might involve a way of thinking that remotely resembles to functional programming, it is way too simplistic for comparison with real world functional programs, at least in my experience. I know I grasped SQL really quickly, and still get puzzled by Haskell after 6 months of trying.
- fusiongyro 14y ago
  I disagree with both of you. I think you're underestimating what can be done in SQL--recursive queries and correlated subqueries are not part of most competent developers' "standard toolkit"--but I think you're illustrating the problem with the OP's point, which is that most competent developers get through joins and outer joins (usually inheriting a lot of weird mythology like "joins are expensive") and can select/project and that's about where the skills end. So while I disagree with you in principle, in practice most people's SQL skills are inadequate even for an analogy to functional programming. I would not say that the thought process I use when writing SQL queries is "more like" my thought process when doing functional programming than imperative programming. In truth, the similarity is all in what isn't present: I'm not deeply worried about what the machine is going to do with my request and how it's going to process it. I remain cognizant of what's "really happening" to the extent that I want to avoid obvious performance pitfalls, but it doesn't become the overriding obsession that it is with procedural programming. With declarative programming I worry much less about whether the result is correct, and this is the primary benefit to me.
- tel 14y ago
  Haskell isn't just FP. It has a lot of other stuff, orthogonal stuff---most notably the HM type system---which really helps to take advantage of "pure" FP. Getting bogged down in Haskell doesn't mean that SQL doesn't have a lot of great compositional aspects that are inherited from its "more functional" nature.
- jeffdavis 14y ago
  "[SQL] is way too simplistic for comparison with real world functional programs" Another way of interpreting that is that the ideas behind SQL are so powerful that it's able to be one of the most successful programming languages of all time without all the bells and whistles of a language like haskell. It's so successful that it can get by with horrid syntax, a ton of special cases built in, and the mess of SQL NULL semantics. Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful. I don't necessarily disagree with you, depending on what you mean by "real world" programs. I just think that if there is already an area where the concepts are useful (whether you call that a "real world program" or not), it makes a lot of sense to keep trying to build from that. Trying to convince someone to learn haskell to build a website when they already know and like ruby is an uphill battle.
  - martinced 14y ago
    "Sometimes it boggles my mind that more functional programmers don't get involved in databases, where all of their ideas are already proven to be useful." But some do. For example Rich Hickey used Clojure (which both users and encourages FP but still allows to bend the rules when needed) to create Datomic. It's a DB but it's CRA instead of CRUD. Making it just so much easier to reason about. The DB is ever-growing and any query becomes "query at time t". And later on, when you query again "query at time t", you CANNOT get a different answer. Typical CRUD DBs are place-oriented mutability mess and, honestly, reading about MySQL fanbois vs PostgreSQL fanbois arguing about which one is the best looks, from a CRA point of view, as a blind man arguing with a one-eyed about who has the best eye vision. Datomic is ACID, has infinite read scalability and can use SQL DBs (and many others) as their persistence stores. It is as Real-World as one can get since that Rich Hickey as seen exactly what we're all witnessing daily in the real-IT-world: a gigantic ball of mutability mess. To me the revolution is on and there's no going back for those who switched. From there it's just a matter of time.
    - jeffdavis 14y ago
      Thank you. I knew that Datomic existed, and some of the basic things you pointed out here, but I'll take a closer look. It seems like you really think it has a lot of promise. That being said, I don't think CRA is a panacea. Databases will always have a "read, decide what to do, write" pattern (because that is what happens in the real world, and databases model the real world). If the read happens at time T, and the write happens at time T+100; then you could have a race condition if something happens at time T+50. Postgres can detect such race conditions by using true serializability (based on a technique called Serializable Snapshot Isolation[1]). It gets tricky to apply the same technique for temporal databases, though I believe it's possible. Do you happen to know what techniques Datomic offers users to help avoid/detect/resolve race conditions? Don't get me wrong. I think it's a very useful direction to go in. I've done a lot of work on temporal features in postgres. I'm also aware of some of the limitations, however. You still need some kind of coordination and something resembling locks or a conflict detector. (By the way, please avoid derogatory comments about people who make different technology choices than you do. An argument could be made that postgres is CRA. And even if not, CRA versus CRUD is a small part of what is actually important to users; many of whom face a different set of trade-offs than you do.) [1] http://drkp.net/papers/ssi-vldb12.pdf http://drkp.net/papers/ssi-vldb12.pdf
tikhonj 14y ago
This general idea is well illustrated by LINQ: it essentially garbs basic functional programming into SQL's garments and passes it off to C# programmers, who happily use it for a whole bunch of different things. Some of these things (like RX) are really nothing like normal SQL at all.
agumonkey 14y ago
And it's probably a matter of ecosystem too. Outside databases you end up depending on stateful libs/components so you're kinda forced to go with the flow, too much inertia.
jeffdavis 14y ago
In many ways, SQL is the case that proves how important and practical some functional language ideas are. SQL is, by many measures, one of the most successful programming languages of all time.

Chris_Newton 14y ago

Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation; - a common set of basic data structures (set, sequence, dictionary, tree, etc.) and generalised operations for manipulating and combining them (map, filter, reduce, intersection, union, zip, convert a tree to a sequence breadth-first or depth-first, etc.); - a more declarative programming style, writing specifications rather than instructions; - a programming style that emphasizes the data flow more than the control flow. I see these as distinct, though certainly not independent, concepts. I’m not sure whether functional programming itself is really on the rise, not to the extent of becoming a common approach in the mainstream programming world any time soon. I don’t think we’ve figured out how to cope with effectful systems and the real world having a time dimension very well yet. (I don’t think we’ve figured it out very well in imperative programming yet either, but the weakness is less damaging there because there is an implicit time dimension whether you want it or not.)

rayiner 14y ago
What is your third point if not functional programming?
- ufo 14y ago
  declarative vs imperative is kind of a subjective thing but functional programming is not the only way to do declarative programming (logic programming and SQL are two examples that come to mind)
- Chris_Newton 14y ago
  Functional programming, by definition, is expressing a program as a function to be evaluated. That implies that, at least to some extent, all functional programs are written in a declarative style. However, we use a declarative style for other kinds of language as well: Prolog, SQL and CSS are three very different examples, none of which is a functional programming language similar to ML or Haskell or Clojure.

rdtsc 14y ago

I think a big one is concurrency. Highly concurrent application will become more popular. Functional programming via immutable data structures is one sane way to manage that. Clojure is doing it. Erlang has been doing it for years. Haskell has that. Fear of large, mutable state is well founded. What else I think is healthy is adoption of these patterns. It is possibly to be diligent and try to apply some of the idea using other languages (C++, Python etc). It is just a different way of thinking and structuring code.

spikels 14y ago

Why is functional programming on the rise? I have heard several times that the big payoff with function programming comes from parallel processing. Because functions typically have no side effects they can operate on a set of inputs in parallel without modification. This is important because future increases in processing power are expected to come primarily from more cores rather than higher clock speeds as in the past. Is this correct? The author seems to focus on other real but lesser benefits.

PeterisP 14y ago
I've done a bunch of both 'classic' and functional programming, and for me the biggest difference is a switch in code-writing mindset. In imperative languages, generally, I tell the computer what and how it should do - no matter if it's assembly, C, Java or [most of] Ruby. In FP languages (Haskell or Scala, haven't worked with Lisps), I generally tell the computer what needs to be computed and expect it to figure out how to do it - what order of execution, what grouping of data, what to cache. If you compare Java code and Scala code for the same algorithm, using the same JVM API - then the main nonsyntactic difference between them will be a pile of missing Java lines detailing the order of processing steps and loops, which probably weren't essential to the algorithm - when writing the Java code I could've written it in opposite way with the same result. What I lose in FP is the ability to easily explicitly do time/space tradeoffs. Sometimes I need to control that, and then it's a bit trickier. However, it can be fixed with minor refinement of language and libraries - the original article cites a great example on how memoization should be implemented in all great languages. Parallelism currently is just a nice bonus - say, I lose 3x performance by not detailing a great execution path manually in C++; but I gain 3x performance since most of the code is trivially parallelizable to run on 4 cores. For example, in Haskell it's often literally a one-line change, while in Java it'd be a pain in the butt to make everything safely threaded.
- mikecsh 14y ago
  This is one of the clearest and most concise explanations on the benefits of FP that I have seen. Thanks!
- 14y ago

stmartin 14y ago

YAWN

ilaksh 14y ago

Highly recommend LiveScript if you like CoffeeScript or JavaScript or functional programming. http://livescript.net http://livescript.net

fourstar 14y ago
Any reason why they ripped the original name for Javascript off? I totally thought you were joking until I went to the site and noticed it's a current project.
- GeZe 14y ago
  The name is a joke, the project is not. "LiveScript was one of the original names for JavaScript, so it seemed fitting. It's an inside joke for those who know JavaScript well." (from the site) LiveScript hasn't been used as a name for JavaScript in almost two decades.
  - fourstar 14y ago
    Thanks for explaining.
cpeterso 14y ago
LiveScript was the original name for JavaScript in Netscape Navigator 2.0's beta releases.

neur0 14y ago

Quite off-topic, but the underscores for the variable names in the first code snippet are totally irritatingly useless and anachronistic in the most ugly looking way.

efnx 14y ago
They mark the private variables so you don't have to remember which ones are private when you read further down the page. That's pretty common place and good style, IMO. What makes you think they're anachronistic?

taeric 14y ago

Doesn't this just bend back to Moore's law? Sure, there are more "efficient" data structures for use in functional styles now than there were in the past, but they all seem to treat memory as if it is free. Basically, now that we have such impressive computing resources, we can start thinking of the programs we are writing in terms of the abstractions themselves, and less in terms of the abstraction that is the computer. (That is, many of us are lucky enough to not worry about caching strategies, threading concerns, etc.) The entire debate about immutable structures is amusing when you consider old resources where there is not spare room for a new copy of a string just from a different starting point. (Referring to the new Java behavior of .substring)

slyv 14y ago

I have been meaning to dig deeper into functional programming, specifically Clojure, but as a newbie to functional programming, I am finding it hard to find a detailed tutorial that I can start to get started with the concepts and programming used in Clojure. Would anyone have any recommendations for a guide?

billsix 14y ago
pg's "ANSI Common Lisp" and "On Lisp" are both great. Your question was about Clojure, but the material in those books is easily transferable to other lisp dialects.
espeed 14y ago
Programming Clojure by Stuart Halloway is the clearest introduction to Clojure I've read: http://www.amazon.com/Programming-Clojure-Stuart-Halloway/ http://www.amazon.com/Programming-Clojure-Stuart-Halloway/
pearle 14y ago
This site is a bit old now (not sure if it's kept up to date) but I found it helpful when I first started playing with Clojure several years ago (wow...that long already)? http://java.ociweb.com/mark/clojure/article.html http://java.ociweb.com/mark/clojure/article.html

justin_vanw 14y ago

They are assuming that functional programming is on the rise. With the exception of Clojure (which is more popular by virtue of being new), I don't know of any functional language that are in any measurable way more popular (I assume that is what they mean by on the rise) than it has been in the last 10 years. In fact, the only application I use that is built using functional programming is Xmonad. Also, none of the top languages on the TIOBE survey are purely functional, although one in the top 20, 'lisp' with .9% and falling, does promote a functional style. People expound the virtues of functional programming year after year, and then go off and get a bunch done with Python. Steve Yegge said it best: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html http://steve-yegge.blogspot.com/2010/12/haskell-researchers-... http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

batgaijin 14y ago
Hypothetically you are a big company able to deliver increasingly complicated software that far outperforms the competition because of functional programming. Would you want to correct a remark like this by IBM? Why on earth would you want to educated pointy-haired individuals when you can be another vapid supporter of the six-sigma model?

goggles99 14y ago

The majority of people Are Lazy - This is why java and other languages abstracted further than C/C++ became so popular. Functional programming is more natural and comes with a smaller learning curve. It does not require the same amount of discipline to become proficient - nor the conceptual, analytical problem solver skills to master. But that is just the language, what about the design of an large scale application suite? So people with less analytic abilities and problem solving skills, (I think of those who HAD TO choose Humanities and arts majors here?) Can actually pick it up. This can be looked at as good or bad, in the long run it is probably good overall because the understanding of hardware and memory become less important as processors, memory, storage, and bandwidth become cheaper There will always be the geeks who still understand everything and can design and architect the software for the developers to code. One downside may be that those with the analytic/problem solving minds will lose their art in a sense and lose the very thing that keeps their minds sharp. Another thing worth mentioning is, there is going to be a lot of changes for developers. Wages will go down as it gets easier to learn how to program - thus more programmers flood the market (supply and demand), also their will be a separation of Architects and code monkeys - the latter being the Humanities graduate type. To sum up - This will "Dumb Down" your average developer and create a clearly defined separation between developers and designers/architects.