Some ideas that are ubiquitous within functional programming are certainly on the rise, for example:<p>- functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation;<p>- 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.);<p>- a more declarative programming style, writing specifications rather than instructions;<p>- a programming style that emphasizes the data flow more than the control flow.<p>I see these as distinct, though certainly not independent, concepts.<p>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.)
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.
I think a big one is concurrency.<p>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.<p>Fear of large, mutable state is well founded.<p>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.
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.<p>In fact, the only application I use that is built using functional programming is Xmonad.<p>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.<p>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: <a href="http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html" rel="nofollow">http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...</a><p><a href="http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html" rel="nofollow">http://www.tiobe.com/index.php/content/paperinfo/tpci/index....</a>
Why is functional programming on the rise?<p>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.<p>Is this correct? The author seems to focus on other real but lesser benefits.
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.)<p>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)
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?
Highly recommend LiveScript if you like CoffeeScript or JavaScript or functional programming.<p><a href="http://livescript.net" rel="nofollow">http://livescript.net</a>
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?<p>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.<p>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.<p>To sum up - This will "Dumb Down" your average developer and create a clearly defined separation between developers and designers/architects.
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.