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.)
To me, the future will most likely be languages that allows both functional and OO styles to interoperate. Programmers will pick the style or mix of styles most appropriate to the particular sub-problem they're solving.
We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constructs. Almost every program I write in these languages uses all of the above, not just the functional or OO subset.
I so far have not seen any practical advantage in going purely functional. I've tried it a number of times, but I always find that the real-world programs I write need to be stateful. Yes, functional languages do of course have facilities for handling state, but they always seem super awkward, especially compared to the elegance of state handling in OOP.
For example, consider a simple, 1980s-style arcade game. There are a bunch of entities on screen, each with attributes like velocity, health, etc.. How do you maintain this state in a purely functional language? I've seen various suggestions, but they all seem to boil down to setting up a game loop with tail recursion, and then passing some game state object(s) to this function on each recursion. Doesn't sound so bad, but what happens when you have a bunch of different types of entities? E.g. player characters, monsters, projectiles, pickups, etc..
Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state a function is updating, because it just receives and returns the big game state hash. You don't really know what data your functions depend on our modify. Effectively, it's almost like you're using global variables.
I'm using games as an example here, but the same sorts of problems come up with almost any stateful application.
This is why I prefer languages that allow you to seamlessly mix functional and OO styles. They give you many of the benefits of FP without forcing you to deal with the difficulties described above.
Yes, a lot of these are characteristic of functional programming, and many are being adopted. But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. And it's this purity that divides the communities. You can take high-order functions and folds and put them in just about any language, and you could put OOP concepts like subtype polymorphism into functional languages. But there's a line that neither class of languages can cross over, and that's mutable state.
I know that some developers are beginning to lean in the direction of functional programming by relying on const annotations and adopting a functional style. And I'm very excited and hopeful about the overall trend.
I tend to agree. It's a lot like with object-oriented programming: "Hey, this is so awesome! You can encapsulate data, have well-defined interfaces, enforce separation-of-concerns, and, and ..." --> Er, I've always been able to do all that, I just didn't call it OO.
That said, I'm still doing what I can to assimilate those techniques and understand where to apply them.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
I heard this too but in my exploration of functional programming I found little to back this up. Automatically deciding whether it's worth running a given function on a different processor or not (i.e. whether the overhead is greater or less than the savings on the wall clock) is not so much different than the halting problem and many implementations either don't try it or don't do it well. Also, every practical functional program needs to deal with the real world, whether it's in a "pure" (Haskell) form or not, and one way or another this introduces ordering constraints that work against parallelization.
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)
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?
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)?
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.
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.
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.
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.
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?
[+] [-] Chris_Newton|13 years ago|reply
- 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.)
[+] [-] jarrett|13 years ago|reply
We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constructs. Almost every program I write in these languages uses all of the above, not just the functional or OO subset.
I so far have not seen any practical advantage in going purely functional. I've tried it a number of times, but I always find that the real-world programs I write need to be stateful. Yes, functional languages do of course have facilities for handling state, but they always seem super awkward, especially compared to the elegance of state handling in OOP.
For example, consider a simple, 1980s-style arcade game. There are a bunch of entities on screen, each with attributes like velocity, health, etc.. How do you maintain this state in a purely functional language? I've seen various suggestions, but they all seem to boil down to setting up a game loop with tail recursion, and then passing some game state object(s) to this function on each recursion. Doesn't sound so bad, but what happens when you have a bunch of different types of entities? E.g. player characters, monsters, projectiles, pickups, etc..
Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state a function is updating, because it just receives and returns the big game state hash. You don't really know what data your functions depend on our modify. Effectively, it's almost like you're using global variables.
I'm using games as an example here, but the same sorts of problems come up with almost any stateful application.
This is why I prefer languages that allow you to seamlessly mix functional and OO styles. They give you many of the benefits of FP without forcing you to deal with the difficulties described above.
[+] [-] jekor|13 years ago|reply
I know that some developers are beginning to lean in the direction of functional programming by relying on const annotations and adopting a functional style. And I'm very excited and hopeful about the overall trend.
[+] [-] rayiner|13 years ago|reply
[+] [-] SilasX|13 years ago|reply
That said, I'm still doing what I can to assimilate those techniques and understand where to apply them.
[+] [-] discreteevent|13 years ago|reply
[+] [-] tikhonj|13 years ago|reply
[+] [-] pestaa|13 years ago|reply
I know I grasped SQL really quickly, and still get puzzled by Haskell after 6 months of trying.
[+] [-] jeffdavis|13 years ago|reply
[+] [-] agumonkey|13 years ago|reply
[+] [-] rdtsc|13 years ago|reply
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.
[+] [-] justin_vanw|13 years ago|reply
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-...
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
[+] [-] batgaijin|13 years ago|reply
Why on earth would you want to educated pointy-haired individuals when you can be another vapid supporter of the six-sigma model?
[+] [-] spikels|13 years ago|reply
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|13 years ago|reply
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.
[+] [-] svachalek|13 years ago|reply
[+] [-] taeric|13 years ago|reply
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|13 years ago|reply
[+] [-] pearle|13 years ago|reply
http://java.ociweb.com/mark/clojure/article.html
[+] [-] espeed|13 years ago|reply
[+] [-] billsix|13 years ago|reply
[+] [-] ilaksh|13 years ago|reply
http://livescript.net
[+] [-] fourstar|13 years ago|reply
[+] [-] cpeterso|13 years ago|reply
[+] [-] goggles99|13 years ago|reply
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.
[+] [-] stmartin|13 years ago|reply
[deleted]
[+] [-] neur0|13 years ago|reply
[+] [-] efnx|13 years ago|reply