By Confusion on Saturday 21 February 2009 22:30 - Comments (61)

Categories: Java, Software engineering, Views: 85.649

Authorities in the field of software engineering have long lamented the fact that functional programming (FP) doesn't seem to catch on. Their sympathizers often blame that on shortcomings in the audience or their pointy-haired bosses, but that is the easy way out: to assume that someone that disagrees with you simply lacks the ability to understand you is a way of shielding yourself from the possiblity that you are the one with a shortcoming: the inability to provide a proper explanation.I think that the actual reason for the limited adoption of FP languages is exactly that: the way the advantages are formulated and exemplified are completely obvious and compelling to their proponents, but those same explanations and examples utterly fail to convince most software engineers, because they simply do not appeal to the problemsare confronted with in their daily line of work.I think this hypothesis is best exemplified by the seminal paper Why Functional Programming Matters . This paper sets out toand then goes on with explanations likeand applications to things like the Newton-Raphson approximation and tree pruning in artifical intelligence.[I'm inserting an intentional dramatic silence here, in which you can see my facial expression turn to complete astonishment]Now how in heavens name can one expect to convince the average software engineer of the tenets of functional programming with these kinds of examples? If it does one thing, it is scaring people away by seeming unnecessarily difficult and academic.Every introduction to a programming language shows you the recursive method to calculate Fibonacci numbers. It's abstract, many people do not relate to it very well, but it's only a single example. However, the documentation for FP languages seem to consist solely of these kinds of highly mathematically inspired examples. No 'Address' class to be found there. Hasn't anyone written a functional equivalent of the Pet Store application to demonstrate the power of FP for the regular work that most of us do?People that want to improve the world often overlook one fundamental problem: you cannot improve the world just by being right. You need to convince others of that fact if you want to exert influence. If you cannot convince them, find out why you cannot convince them. I think there is a bright future ahead for functional programming, as soon as someone stands up to convince the masses.Update:As not everyone reads the comments, I would like to highlight a few points made there:

[..] demonstrate to the 'real world' that functional programming is vitally important, [..] [listing of advantages] Such a catalogue of 'advantages' is all very well, but one must not be surprised if outsiders don't take it too seriously. [..] We must must find something to put in its place - something which not only explains the power of functional programming, but also gives a clear indication of what the functional programmer should strive towards.

03-'09 Writing good code requires you to perform experiments

02-'09 Spring, Hibernate and leaky abstractions

Comments

By Kage, Saturday 21 February 2009 23:36 Exactly why i dont get the fuzz about functional programming. But it sounds like you know more about it than me, could you provide a simple useful, non-abstract example?

I'd really like to learn more about it but it's hard to catch on without any real-life (well programming real life anyway) situations

By Tubbie, Saturday 21 February 2009 23:39 The reason FP-proponents show mathematical examples is because that is what FP excels at. The problem is that most code most programmers write every day is mostly about 'interacting with stuff' (Database, User Interface, etc...), and doesn't really contain any complex math or algorithms.



FP languages are fundamentally different, and they aren't worth learning if it only solves some edge cases.

By Dooievriend, Sunday 22 February 2009 00:19 I agree with Tubbie, FP has other uses than (Object Oriented) imperative programming. I'm still studying to become an ICT-guy one day, and had a course on Prolog, Haskell and Mercury this semester. I liked it a lot, and it is great for solving logical riddles like the Einstein-problem, sudoku's, hitori-puzzles or mathematical problems. Still, after passing the course, I don't have a clue how one would be able to build a gui with it, or how one can easily interact with a database. To me, FP will be used, but only embedded in another language, when complex and often changing problems arise. This is how I believe FP-languages should be utilized, and I know of at least one example where Mercury used in this way was the secret weapon which gave one company its edge over its direct competitors. Though I don't think the average programmer writing an average business application would need a FP language to excel at its job...

By H!GHGuY, Sunday 22 February 2009 08:44 @Dooievriend/Tubbie:

And that's where mixed languages come into play. Mixing imperative languages with functional languages to combine the best of both worlds.

By Confusion, Sunday 22 February 2009 10:55 @Kage:

I intend to try and create those kinds of useful, non-abstract examples, but I'm not sure whether I'll succeed. I certainly don't think they will be simple. One of the main points that the quoted article makes is that FP allows for new ways of modularizing your code. To show the power of that, you need an example that requires modularization and that almost certainly means a large bit of code. Another major argument in favor of FP is the way immutable data and side-effectless functions prevent bugs, but to demonstrate that, you need an example with an insidious bug, which is hardly ever simple. Those same aspect mix very well with concurrent programming, but I think demonstrating the advantages in concurrent programming also requires a complex example.



@Tubbie&Dooievriend:

I fully agree with H!GHGuY: mixed languages are the key to the adoption of FP languages. I have developed and interest in Scala, which I think looks extremely promising.

By Jack, Sunday 22 February 2009 14:49 Although I agree that most introductions to functional languages (and application as a whole) are academic, this does not that there aren't any good examples out there on how they can be used. E.g.: take a look at Practical Common Lisp http://www.gigamonkeys.com/book/ . I have to admit it isn't purely functional, though. The above comments on mixed languages are probably right. Heck, even C# supports lambda expressions nowadays!

By RayNbow, Sunday 22 February 2009 17:24





@blog post:

"Every introduction to a programming language shows you the recursive method to calculate Fibonacci numbers. It's abstract, many people do not relate to it very well, but it's only a single example. "



The Fibonacci example (but also factorial) is often used as a concrete example of the language's syntax. Since functional programming languages are centered around functions, what could be a better way to show how to define them? You could say Fibonacci and factorial are the Hello World of the functional world.



@Jack:

"Heck, even C# supports lambda expressions nowadays!"



Not only that, it even has @Dooievriend: Real World Haskell is a book about the purely functional programming language Haskell and tackles problems such as parsing, web programming, databases, and GUIs.@blog post:"Every introduction to a programming language shows you the recursive method to calculate Fibonacci numbers. It's abstract, many people do not relate to it very well, but it's only a single example. "The Fibonacci example (but also factorial) is often used as a concrete example of the language's syntax. Since functional programming languages are centered around functions, what could be a better way to show how to define them? You could say Fibonacci and factorial are the Hello World of the functional world.@Jack:"Heck, even C# supports lambda expressions nowadays!"Not only that, it even has monads!

By Morton, Sunday 22 February 2009 18:12 I agree with your central argument, but I see fewer such toy examples every year. I think language designers and advocates are starting to realise the importance of useful, real-world examples. Here's hoping these kinds of examples continue fading into obscurity.



However, I have a tough time seeing where is FP *not* catching on. I often find co-workers using functional patterns in their code without even realising it. It is getting more difficult to find languages that do not have (or plan to support) advanced FP. When Java and .NET decide to start supporting FP concepts, you've got to wonder who thinks FP hasn't caught on.

By dons, Sunday 22 February 2009 19:54 You're attacking a strawman: Why Functional Programming Matters was written 25 years ago...



Why not contrast with how FP languages are introduced in 2009. See e.g. Real World Haskell: full of web, gui, database, concurrent servers, and even bloomfilters for fun. All in an introductory text.



The programming universe of 2009 is very different to that of 1984.

By Alex, Sunday 22 February 2009 20:58



I am enjoying the adavantages because I went out and learned functional programming and discovered for myself what the advanatages are.



I (and my team) have developed a substantial, real world, commercially available and purchased by large companies, business application in F#. The win is that there is a reduction in code written from 4 to 10 times depending on the nature of the task. We know this very specifically because we had some historical code that we re-wrote in F#. The code is also significantly more maintainable and more extensible.



Of course this gives us a competitive advantage. So maybe it is good that most are not convinced. I have this secret weapon all to myself Is your point that no one has yet written an article that convinces YOU of the advantages of Functional Programming?I am enjoying the adavantages because I went out and learned functional programming and discovered for myself what the advanatages are.I (and my team) have developed a substantial, real world, commercially available and purchased by large companies, business application in F#. The win is that there is a reduction in code written from 4 to 10 times depending on the nature of the task. We know this very specifically because we had some historical code that we re-wrote in F#. The code is also significantly more maintainable and more extensible.Of course this gives us a competitive advantage. So maybe it is good that most are not convinced. I have this secret weapon all to myself

By Confusion, Sunday 22 February 2009 21:06

Thank you, that link looks promising.



@Alex:

I am convinced . The point of the blogpost was an idea on why many others do not seem convinced.



@dons:

The example may have been unfortunate, but I intended it as an (exaggerated) example of what documentation of FP languages tends to look like. I cannot take a look at Real World Haskell without buying it; do you know of other Haskell examples that would falsify my hypothesis?



@RayNbow:

I intended to say that it is all and well that Fibonacci may be found in the documentation for *any* language, but that the documentation for FP languages seems to consist solely of that kind of mathematically inspired examples. @ Jack:Thank you, that link looks promising.@Alex:I am convinced. The point of the blogpost was an idea on why many others do not seem convinced.@dons:The example may have been unfortunate, but I intended it as an (exaggerated) example of what documentation of FP languages tends to look like. I cannot take a look at Real World Haskell without buying it; do you know of other Haskell examples that would falsify my hypothesis?@RayNbow:I intended to say that it is all and well that Fibonacci may be found in the documentation for *any* language, but that the documentation for FP languages seems to consist solely of that kind of mathematically inspired examples.

By necrobious, Sunday 22 February 2009 21:16 @dons, agreed. I've been making my way through Realworld Haskell ( http://book.realworldhaskell.org/ ) in my spare time, and have been amazed at how much useful information is packed into that book. Its being called the 'pickaxe book' and the 'camel book' for haskell and defiantly worth picking up

By Dennis, Sunday 22 February 2009 21:20 I'm not using a functional language yet in production, but I am using functional techniques in C#, even for some very mundane stuff. Validating Excel uploads, for example. I used lexical closures to build a DSL, that let me very easily specify validation rules involving logical combinations of cells. It's the same sort of coding they were doing in that definition of reduce, but using a mainstream language for a very prosaic task...with the end result that I save myself an awful lot of boring repetitive work.

By Confusion, Sunday 22 February 2009 22:00 @RayNbow:

Thanks, I overlooked the online version of the book.

By Fritz, Sunday 22 February 2009 22:11

<a href="http://www.ternarysoftware.com/blogs/2009/02/21/playing-with-haskell-http-server/">Playing with Haskell - HTTP server</a>. And there are may other examples, especially lately.



On the other hand, there are still FP people out there who would just as soon you <i>didn't</i> think of FP as a great tool: I'm thinking here of Paul Graham and the whole "FP as secret weapon" meme.



Finally, there are a lot of people who really aren't that concerned about how practical FP is, they're just interested in for abstract mathematical aesthetics, blah blah blah. (I'm probably guilty of this, but then I teach at a liberal arts college, so I'm allowed .) "Avoid success at all costs" is the unofficial slogan of (at least a certain crowd of) Haskellers.



What's really interesting, however, is that many of the real practical advantages of FP arose out of this very lack of concern for practical utility. This is the "unreasonable effectiveness of mathematics" phenomenon described by the physicist Eugene Wigner. Perhaps the best strategy to find deep, long-lasting and profound advantage for real-world work is to take this seemingly paradoxical approach: studiously ignore practical considerations, on the one hand, in order to develop good theory; then, later, turn back to apply the more powerful tools you discover that way. This strategy has worked for mathematics for thousands of years, after all, and the overall dialectical process has been institutionalized in the disciplinary structure of pure and applied mathematicians, scientists and engineers that have brought us modern technology. Perhaps we shouldn't be surprised if this structure evolves in computing as well. On the one hand, Don (dons) has it right: FP has come a long way in terms of practical stuff. For another example (besides the Real World Haskell book), see this post (also featured on reddit) about someone's very positive experience putting a web server together with Haskell:Playing with Haskell - HTTP server. And there are may other examples, especially lately.On the other hand, there are still FP people out there who would just as soon you didn't think of FP as a great tool: I'm thinking here of Paul Graham and the whole "FP as secret weapon" meme.Finally, there are a lot of people who really aren't that concerned about how practical FP is, they're just interested in for abstract mathematical aesthetics, blah blah blah. (I'm probably guilty of this, but then I teach at a liberal arts college, so I'm allowed.) "Avoid success at all costs" is the unofficial slogan of (at least a certain crowd of) Haskellers.What's really interesting, however, is that many of the real practical advantages of FP arose out of this very lack of concern for practical utility. This is the "unreasonable effectiveness of mathematics" phenomenon described by the physicist Eugene Wigner. Perhaps the best strategy to find deep, long-lasting and profound advantage for real-world work is to take this seemingly paradoxical approach: studiously ignore practical considerations, on the one hand, in order to develop good theory; then, later, turn back to apply the more powerful tools you discover that way. This strategy has worked for mathematics for thousands of years, after all, and the overall dialectical process has been institutionalized in the disciplinary structure of pure and applied mathematicians, scientists and engineers that have brought us modern technology. Perhaps we shouldn't be surprised if this structure evolves in computing as well.

By Don Stewart, Sunday 22 February 2009 22:45 @Confusion yep, as others have pointed out, RWH, 25 years after "Why FP Matters" is online and free. To really hammer home how things have shifted from the abstract to the concrete, consider what one Amazon reviewer said:



" [RWH]cover[s] the same amount of material the examples cover in another more mainstream language would have taken several more pages if not multiple volumes. How many books cover file processing, regex, parsing, network programming, we programming, system programing, GUI programming and 2 different concurrency mechanisms while teaching a new language all that in around 600 pages "



So I think we have a constructive proof that the FP community is taking practical teaching and application very very seriously. We're all about pragmatics.

By Petey, Monday 23 February 2009 00:55 To see how FP is useful, look at Ruby on Rails. Or even the higher-level primitives in Python (e.g. list interpretations). Many of the core design patterns from Scheme and Lisp are gradually moving into mainstream languages, but in a less abstract, more explicit way.

By Tony Morris, Monday 23 February 2009 01:46 Unconvincing. Nope sorry, I still think it is the anti-intellectualism of the pragmatists who have infected the industry.

By BMeph, Monday 23 February 2009 05:16



Anyway, going along with the "secret weapon" theme: Since writers in both @dons You know, you should add a "full disclosure" blurb to your post about RWH, considering you are one of its authors, and therefore directly benefit when people get "hooked" by Haskell and buy the book...Anyway, going along with the "secret weapon" theme: Since writers in both Javascript and php have added functions for programming in a functional style, it seems that the secret is out, and being catered to by those in the know.

By MeBigFatGuy, Monday 23 February 2009 05:48 At the end of the day, the language doesn't really effect the normal programmer. It's the size of the pool of well written libraries that matter. That's why Java stomps on other languages.

By ekzept, Monday 23 February 2009 07:07 FP demands a massive change to the programming mindset. There are programmers, for example, who see reduce or map and say "Well, that's just a loop". It's not. That's one possible implementation of it. They are so committed to that way of thinking that they cannot see things done any other way.



But take a loop, take any program fragment. The FP approach can be thought of as asking and seeking ultimate questions of program parameterization. If I write a loop, why can't I pass it the body of the loop as a parameter? Why can't I pass a portion of the body as a parameter so I can use it elsewhere?



Recall that one of the earlier major OO languages, Smalltalk, did and does have FP constructs tied to its Sequence classes. That subsequent OO opted to abandon these and other dynamic constructs was a step backwards, not an improvement.



BTW, Java may "stomp" on other languages but its primacy isn't without significant question in certain fields. Few people working numerics would give up LAPACK, or LINPACK, or NAG. Java has issues with bare hardware. Java's libraries are ossified about a certain way of moving data around which may not lend itself to new ways of data management, including ones where the relational database no longer plays such an important role *especially* for big datasets. Java can be awkward to use in mixed (programming) language settings.



I'm pessimistic that producing "practical packages" in FP will turn the tide. We have those already, as the writings of Paul Graham show (although he speaks about LISP). And there's success to be had on a big scale, as Ericsson's Erlang demonstrates. I think this is about the nature of programmers committed to The Way They Now Know How To Do Things rather than anything about FP.

By Confusion, Monday 23 February 2009 07:15 @Tony Morris:

Many in the industry simply aren't intellectuals. It's not anti-intellectualism: it's non-intellectualism. If FP is really only for intellectuals, then everyone writing in favour of it is mostly preaching to the quire.



Moreover, pragmatism cannot 'infect' an industry: capitalist markets force industries to be as pragmatic as possible. However, as FP has distinct advantages, pragmatism includes FP.

By Paul, Monday 23 February 2009 09:03 So then the best of both worlds would be functional programming on the JVM? That must be why I'm so excited about Clojure

By Tony Morris, Monday 23 February 2009 10:18 @Confusion

I disagree. It is the anti-intellectuals. Children can learn pure functional programming. In fact, both of my two have - I put their standard well above that of my former IBM colleagues bashing away in their Java IDE and they are just normal kids. I know of other children who have done same.



Functional Programming has caught on quite a lot. To the extent that it hasn't is the same extent to which pragmatism has indeed corrupted the faculties of reason (PS: pragmatism doesn't mean what you think it means).

By Peter Svensson, Monday 23 February 2009 10:34



Also, AFAIK it also implies being able to declare anonymous functions, which make it possible to do memoization and other cool generator-like stuff



The most simple practical benefit I've had in using functional languages (JavaScript) has been to use callbacks in a simple manner. I declare a function once, and then pass it as an argument to another function.



Another very useful thing is to be able to collapse the five-ten lined loop into one line, when all you want to do is iterate of one object and either return another (map), check if some or all of the items meet a test (filter) and so on.



These are pretty practical things, all of them.



See Eugene Lazutkins very good (and practical) blog on some use-cases;



http://lazutkin.com/blog/...onal-fun-javascript-dojo/



Cheers,

PS Functional programming is to have functions as variables. This means you can pass them along as parameters, and also define them on the fly in a function call.Also, AFAIK it also implies being able to declare anonymous functions, which make it possible to do memoization and other cool generator-like stuffThe most simple practical benefit I've had in using functional languages (JavaScript) has been to use callbacks in a simple manner. I declare a function once, and then pass it as an argument to another function.Another very useful thing is to be able to collapse the five-ten lined loop into one line, when all you want to do is iterate of one object and either return another (map), check if some or all of the items meet a test (filter) and so on.These are pretty practical things, all of them.See Eugene Lazutkins very good (and practical) blog on some use-cases;Cheers,PS

By Nitin Bharti, Monday 23 February 2009 15:55 Hi Confusion,



Great post! I was unable to find your email address, which is why I'm submitting this request here. I was wondering if we could get your permission to feature this piece in our JavaLobby Newsletter. It will be going out tomorrow morning to approx 93K subscribers.



If you're interested, feel free to reach me at nitin@dzone.com.



Thanks,

Nitin Bharti

Publisher, DZone

By MrX, Monday 23 February 2009 16:20 @Confusion:

As a non-FP man, this seems like an insightful blog.



FP has always had something almost mythical to me: it seems extremely useful at things that I don't understand and am not required to understand for my work. It might be useful to me, but I wouldn't know how or where to look. And as soon as I'd say that out loud, I'd have people telling me about learning a new language that I cannot use in my work environment such as Haskell.



Sure, I could spend a lot of time understanding it all and only then find out its usefulness, but it would require a lot of time, which I don't have. I need to be convinced quickly that every hour I invest in learning something new will be payed back over a reasonable amount of time or I'll defer learning until I'm forced to.



@Tony Morris:

Your comments are exactly the kind of snobbish, elitist and excluding comments that hold back progress. You might have the best tool / language / technique / etc. in the world, but when you belittle people who don't use it / understand it / etc., this perfect thing will hardly ever get used because you drive people away from you and as such, it. You might be very good at software engineering, but you, sir, suck at people skills. If you enjoy being right and all alone in a high and mighty tower, be sure to keep it up.

By Steven G. Harms, Monday 23 February 2009 17:11 I write Perl, functionally.



Why:



1. I work alone, pretty much.

2. I work on a lot of projects quickly, and when I have a bug in one of them, it's very easy to debug





sub main

{

bin(bar(boo(foo(@ARGV))))

}





does something you don't like, it's incredibly easy to debug.



Break in foo, did I get the data I expected? What did I send up the stack?



Maybe I'm just way too un-fancy about this programming stuff, though, but why not just say



"FP is really easy to debug since all those side effects are gone" ?

By Gabe da Silveira, Monday 23 February 2009 19:17 I studied Scheme in my undergrad and enjoyed it, but did not grok FP per se. Like functional code itself, the explanation (elimination of side effects) is elegant to the point of triteness. However I think people need to feel the pain of working with and maintaining large imperative code structures to really understand the need for FP. The trouble with this is that the type of bugs that arise are disparate in nature, and not readily associated with the more general problem (pervasive state). A programmer without exposure to FP will simply look for an immediate solution rather than thinking "there must be a better way." The core problem is that it's hard to break through and communicate a solution not only to the problem at hand, but 10,000 other likely bugs that are just waiting to bite you in the ass.

By bulle bas, Monday 23 February 2009 22:28

I am trained in OOP, and it took about a year to change my hate towards FP (Haskell) into a deeper understanding of the merits of FP above OOP. Current OOP languages are really dumb once you know about what you can easily achieve in FP. Note that some OOP design patterns are direct part of the FP paradigm.

Switching from pure OOP to FP is a pain, but switching back to pure OOP once you've learned FP is a pain too.



The fp community consists of people who don't shave themselves, don't know about fashion and are generally a few times smarter than the average programmer. Ok,ok, not always true. I mean that fp people are generally clever people that love to explore new algorithms and exotic techniques. They tend to love mathematics. This means that there examples and their research is less accessible. Like the author of the blog post I feel these examples are less down to earth.



It takes you time to learn the fp paradigm. To start off, you could study functions as a first

class citizen in JavaScript. This really helps to get the core idea.

You could then move on to Haskell,





Programs written in Haskell tends to be several times smaller than there pure OOP counterparts. This is better for maintainability, testability and other -illities.

Also, the rise of multi core systems and the death of concurrency by threads and locking mechanisms opens the way for languages like Haskell, since multi-core programming is an easy piece in u pure functional language. There have been made some very insightful remarks here already.I am trained in OOP, and it took about a year to change my hate towards FP (Haskell) into a deeper understanding of the merits of FP above OOP. Current OOP languages are really dumb once you know about what you can easily achieve in FP. Note that some OOP design patterns are direct part of the FP paradigm.Switching from pure OOP to FP is a pain, but switching back to pure OOP once you've learned FP is a pain too.The fp community consists of people who don't shave themselves, don't know about fashion and are generally a few times smarter than the average programmer.Ok,ok, not always true. I mean that fp people are generally clever people that love to explore new algorithms and exotic techniques. They tend to love mathematics. This means that there examples and their research is less accessible. Like the author of the blog post I feel these examples are less down to earth.It takes you time to learn the fp paradigm. To start off, you could study functions as a firstclass citizen in JavaScript. This really helps to get the core idea.You could then move on to Haskell, real world haskell might be a good resource.Programs written in Haskell tends to be several times smaller than there pure OOP counterparts. This is better for maintainability, testability and other -illities.Also, the rise of multi core systems and the death of concurrency by threads and locking mechanisms opens the way for languages like Haskell, since multi-core programming is an easy piece in u pure functional language.

By bulle bas, Monday 23 February 2009 22:30 quote: Steven G. Harms "FP is really easy to debug since all those side effects are gone" ? It is possible to use FP with side effects. It is possible to use FP with side effects.

By RayNbow, Monday 23 February 2009 23:53 Sure, I could spend a lot of time understanding it all and only then find out its usefulness, but it would require a lot of time, which I don't have. I need to be convinced quickly that every hour I invest in learning something new will be payed back over a reasonable amount of time or I'll defer learning until I'm forced to. It might be unreasonable to expect to learn new concepts within the smallest time span possible and expect to reap the most benefit. Learning costs time.



For example, ask yourself, how long did it take you to become a good imperative programmer? If possible, try to dig up some old code from when you were just a beginner (say, 1 year after you started programming) and compare it to something you have written recently. Probably you'd notice you have grown a lot as a programmer.



Learning a (total) new concept such as functional programming and to fully benefit from it also takes a lot of time. You cannot expect to be able to master it within a small time frame, just like it is impossible to completely convince someone of its benefits with just a few sentences. Only by undertaking the journey to understand (parts of) the concept one can convince oneself.



The barriers to Functional Programming are the many preliminaries. Functional languages often have a syntax deviating from mainstream languages. While it is a minor problem, it does scare off the new people. The different syntax, however, suits the functional paradigm, just like (domain specific) languages as SQL and LINQ have a syntax suitable for querying data. Learning the syntax is learning to read.



The next barrier is to understand what you have read. What does it mean? For the imperative world, most of us here already have a certain mental model of how the computation takes place, namely by executing statements step by step, altering a global state. In the (purely) functional world, the model of computation is nothing more than a certain way of evaluating expressions, reducing them to simpler expressions. This process resembles what we did in our math classes (algebra) in high school, where we simply replaced variables with their values. Learning this model is needed to be able to understand what's going on.



But this is not all there is to it. Being able to read and understand a language, does not automatically mean we can express our thoughts in it, or at least not very well. People learn to express themselves through practice. By building small programs one after another, first by copying examples, then by altering them, we develop a deeper insight.



The problem here is that people often want to create something tangible and cool, i.e. something involving I/O such that a running program's behaviour is observable (other than your computer box getting hot). A program performing I/O is a somethig that alters some external state. This does not directly fit into the functional programming model and thus I/O has always been a bit tricky.



Even in Haskell, where I/O actions have beautifully been modeled using monads, explaining how I/O works is not something you want to burden a beginner with. This puts us in a dilemma. We want beginners to play and create cool things, but we don't want to overload them with all the nitty details. The unfortunate result is that I/O (and monads) are introduced late in books and tutorials (so no "Hello World" as a first greeting).



The challenge perhaps here is to present a simplified view on I/O, such that we can introduce it earlier, and revisit I/O when the beginner has become more familiar with FP. (You might compare this to teaching Bohr's atomic model in chemistry class before teaching the orbital model.) On the other hand, give I/O to beginners too early and they may stray off the path to the Dark Side, falling back to their old behaviour and solving their problems in their old and customary, stateful way.



Now, I noticed I kinda drifted off so I'll stop typing for now. If you want a (3 hours) Haskell crash course, you could watch Simon Peyton-Jones' talk "A Taste of Haskell" ( @MrX:It might be unreasonable to expect to learn new concepts within the smallest time span possible and expect to reap the most benefit. Learning costs time.For example, ask yourself, how long did it take you to become a good imperative programmer? If possible, try to dig up some old code from when you were just a beginner (say, 1 year after you started programming) and compare it to something you have written recently. Probably you'd notice you have grown a lot as a programmer.Learning a (total) new concept such as functional programming and to fully benefit from it also takes a lot of time. You cannot expect to be able to master it within a small time frame, just like it is impossible to completely convince someone of its benefits with just a few sentences. Only by undertaking the journey to understand (parts of) the concept one can convince oneself.The barriers to Functional Programming are the many preliminaries. Functional languages often have a syntax deviating from mainstream languages. While it is a minor problem, it does scare off the new people. The different syntax, however, suits the functional paradigm, just like (domain specific) languages as SQL and LINQ have a syntax suitable for querying data. Learning the syntax is learning to read.The next barrier is to understand what you have read. What does it mean? For the imperative world, most of us here already have a certain mental model of how the computation takes place, namely by executing statements step by step, altering a global state. In the (purely) functional world, the model of computation is nothing more than a certain way of evaluating expressions, reducing them to simpler expressions. This process resembles what we did in our math classes (algebra) in high school, where we simply replaced variables with their values. Learning this model is needed to be able to understand what's going on.But this is not all there is to it. Being able to read and understand a language, does not automatically mean we can express our thoughts in it, or at least not very well. People learn to express themselves through practice. By building small programs one after another, first by copying examples, then by altering them, we develop a deeper insight.The problem here is that people often want to create something tangible and cool, i.e. something involving I/O such that a running program's behaviour is observable. A program performing I/O is a somethig that alters some external state. This does not directly fit into the functional programming model and thus I/O has always been a bit tricky.Even in Haskell, where I/O actions have beautifully been modeled using monads, explaining how I/O works is not something you want to burden a beginner with. This puts us in a dilemma. We want beginners to play and create cool things, but we don't want to overload them with all the nitty details. The unfortunate result is that I/O (and monads) are introduced late in books and tutorials (so no "Hello World" as a first greeting).The challenge perhaps here is to present a simplified view on I/O, such that we can introduce it earlier, and revisit I/O when the beginner has become more familiar with FP.On the other hand, give I/O to beginners too early and they may stray off the path to the, falling back to their old behaviour and solving their problems in their old and customary, stateful way.Now, I noticed I kinda drifted off so I'll stop typing for now.If you want a (3 hours) Haskell crash course, you could watch Simon Peyton-Jones' talk "A Taste of Haskell" ( part 1 FLV ]) ( part 2 FLV ]) ( PDF slides ).

By Martin Sturm, Tuesday 24 February 2009 18:42 I think there is a point in this article, but it is written at the wrong time. At the moment I see a increasing interest in functional programming by developers who do not have a real academic background (and as a result often didn't learn a functional language during their study). The main reason for this is (I think) the new languages which mix functional and non-functional paradigms such as Scala and Fan (and I think F#, but I don't know this language well enough to be certain that it also allow non-functional stuff). As a result of the increasing popularity of Scala (among Java developers, since that is the world I work in), developers also start to gain interest in more pure functional languages such as Haskell and (common) Lisp (or Clojure). There are definitely some areas in 'real world' programming which can benefit from functional programming solutions.

By joe programmer, Thursday 18 June 2009 03:08 Perl/Python/Ruby = Britney Spears, Lindsay Lohan (total trash, throw away languages for throw away programs, bitrot accelerated)

Java = Spice Girls, New Kids on the Block (marketing driven drivel)



C/C++ = Tool, Metallica (causing of much angst, though not so bad for it's purpose)

Asm = Rap (potentially interesting, but lacking dimensions)



Prolog = Beethoven

SmallTalk = Mozart

Lisp = Bach

By mack, Tuesday 18 May 2010 11:40 Because all those advantages are also disadvantages.



Stateless programs; No side effects



Real-world programs are all about side effects and mutation. When the user presses a button it's because they want something to happen. When they type in something, they want that state to replace whatever state used to be there. When Jane Smith in accounting gets married and changes her name to Jane Jones, the database backing the business process that prints her paycheque had better be all about handling that sort of mutation. When you fire the machine gun at the alien, most people do not mentally model that as the construction of a new alien with fewer hit points; they model that as a mutation of an existing alien's properties.



When the programming language concepts fundamentally work against the domain being modelled, it's hard to justify using that language.



Concurrency; Plays extremely nice with the rising multi-core technology



The problem is just pushed around. With immutable data structures you have cheap thread safety at the cost of possibly working with stale data. With mutable data structures you have the benefit of always working on fresh data at the cost of having to write complicated logic to keep the data consistent. It's not like one of those is obviously better than the other.



Programs are usually shorter and in some cases easier to read



Except in the cases where they are longer and harder to read. Learning how to read programs written in a functional style is a difficult skill; people seem to be much better at conceiving of programs as a series of steps to be followed, like a recipe, rather than as a series of calculations to be carried out.



Productivity goes up (example: Erlang)



Productivity has to go up a lot in order to justify the massive expense of hiring programmers who know how to program in a functional style.



And remember, you don't want to throw away a working system; most programmers are not building new systems from scratch, but rather maintaining existing systems, most of which were built in non-functional languages. Imagine trying to justify that to shareholders. Why did you scrap your existing working payroll system to build a new one at the cost of millions of dollars? "Because functional programming is awesome" is unlikely to delight the shareholders.



Imperative programming is a very old paradigm (as far as I know) and possibly not suitable for the 21th century



Functional programming is very old too. I don't see how the age of the concept is relevant.



Don't get me wrong. I love functional programming, I joined this team because I wanted to help bring concepts from functional programming into C#, and I think that programming in an immutable style is the way of the future. But there are enormous costs to programming in a functional style that can't simply be wished away. The shift towards a more functional style is going to happen slowly and gradually over a period of decades. And that's what it will be: a shift towards a more functional style, not a wholesale embracing of the purity and beauty of Haskell and the abandoning of C++.



I build compilers for a living and we are definitely embracing a functional style for the next generation of compiler tools. That's because functional programming is fundamentally a good match for the sorts of problems we face. Our problems are all about taking in raw information -- strings and metadata -- and transforming them into different strings and metadata. In situations where mutations occur, like someone is typing in the IDE, the problem space inherently lends itself to functional techniques such as incrementally rebuilding only the portions of the tree that changed. Many domains do not have these nice properties that make them obviously amenable to a functional style.

By HonestObserver, Tuesday 31 May 2011 21:45 Wow, joe programmer, that may be the worst comment I have ever read on a coding blog. Please go back to trolling YouTube videos.

By James McKay, Friday 14 October 2011 16:01



See also There is one way to introduce functional programming in a pretty convincing way: jQuery. It contains a lot of functional concepts in action in the very practical, down-to-earth, easy to understand environment of web programming.See also http://importantshock.wor.../01/18/jquery-is-a-monad/

By Max Guernsey, III, Friday 14 October 2011 17:30 There is another possible locus of shortcoming: the idea itself. Functional programming might actually just plain not be important at all. It could be that it's not catching on because it's an exceptionally bad idea. It could also be that it's an idea with extremely limited applicability and that it's caught on like wildfire in those few areas where it is even a little useful.

By Jason Shaw, Wednesday 1 February 2012 07:43 We absolutely love your blog and find most of your post's to be precisely what I'm looking for. Can you offer guest writers to write content for you? I wouldn't mind composing a post or elaborating on a number of the subjects you write regarding here.

By DIYA, Sunday 11 March 2012 20:10

Shop Vac I am so much excited after reading your blog. Your blog is very much innovative and much helpful for any industry as well as for person.

By Garrett Ace 350, Wednesday 14 March 2012 07:01 detail were just perfect. I think that your perspective is deep, its just well thought out and really fantastic to see someone who knows how to put these thoughts down so well. Great job on this.

By Garrett Ace 250, Wednesday 14 March 2012 07:12 I'm glad that I had the fortune to stumble across your blog. It’s definitely an important issue that not enough people are talking about and I'm glad that I got the chance to see all the angles.

By Garrett Ace 350 Metal Det, Wednesday 14 March 2012 12:31 I'm glad that I had the fortune to stumble across your blog. It’s definitely an important issue that not enough people are talking about and I'm glad that I got the chance to see all the angles.

By cheap car insurance, Monday 19 March 2012 14:33 Its always good to have tips on good blog posting. As I just started posting comments for blog and faced a lot of rejections. I think your suggestion would be helpful for me. I will let you know if this works for me Thanks and keep posting such a informative blogs.

By hire magento developer, Wednesday 21 March 2012 07:55 Very good and interesting post that i have come across, thanks for sharing the post.

Really appreciated.

By sell wow account, Friday 23 March 2012 08:48 can see that everything on this topic is very amazing and mind blowing, so i have nothing to say here. This has to be one of my favorite posts! And on top of thats its also very helpful topic for newbies. Thanks a lot for informative information . I am just going through all the topics and being

By HUda, Friday 23 March 2012 13:51

rackmount server Great job. Well with your permission allow me to grab your rss feed to keep up to date with incoming post. Thanks a million and please keep up the delightful work.

By sehrish, Sunday 25 March 2012 17:36

supermicro games play an essential role to maintain our health. Games are as important for a body as food is for brain.This article deals with games.

By aaron Mcroiene, Monday 26 March 2012 15:14

tenant screening services this is such a great thing to know "I think that the actual reason for the limited adoption of FP languages is exactly that: the way the advantages are formulated and exemplified are completely obvious and compelling to their proponents, but those same explanations and examples utterly fail to convince most software engineers, because they simply do not appeal to the problems they are confronted with in their daily line of work"..more power

By rocks2010, Wednesday 28 March 2012 18:17

restaurant address Personally i think strongly regarding it and love learning much more about this topic

By gema, Thursday 29 March 2012 17:33 yeah of course. That is also some questions that I keep on Asking on myself too. I just can't take it anymore. mens shoes

By mltd coupon, Friday 30 March 2012 11:50 Loop. I was actually excited enough to leave a leave a responsea response ;-) I actually do have a few questions for you if it’s okay. Could it be just me or does it appear like

By Mama Mia Travel - Online , Friday 30 March 2012 11:52 have something to valuable to contribute to the conversation. Usually it’s a result of the sincerness displayed in the article I looked at. And after this article Sneffels Wildness

By cursuri engleza, Saturday 31 March 2012 05:48 cursuri engleza

I likes stuff like this website and this has now given me A few inspiration To succeed, so Bless you. =) I likes stuff like this website and this has now given me A few inspiration To succeed, so Bless you. =)

By how to repair motorcycle , Saturday 31 March 2012 06:40

Thanks,

how to repair motorcycle fairings I graduated with the course of combination of Business management and Information technology but that time we were not be able to do these functional programming skills.Thanks,

By catering supplies, Saturday 31 March 2012 09:58 Thanks to a brilliant effort in publishing your article. One can be more informative as this. There are many things I can know only after reading your wonderful article

By rocks2010, Monday 2 April 2012 00:03

restaurant database I am very interested in what you write. I think I can understand a lot for me to learn better.

By free vpn service, Monday 2 April 2012 07:29 free vpn service I think that the actual reason for the limited adoption of FP languages is exactly that: the way the advantages are formulated and exemplified are completely obvious and compelling to their proponents, but those same explanations and examples utterly fail to convince most software engineers, because they simply do not appeal to the problems they are confronted with in their daily line of work.

By Blog Commenting Service, Monday 2 April 2012 11:18 I am always searching for quality posts and articles and this is what I found here, I hope you will be adding more in future

Comments are closed