Functional Programming In Industry

Last week attended the International Conference on Functional Programming (ICFP Conference). I attended as what some functional programmers would call their enemy, since like most people, I stick to the widely used imperative languages. There's one difference though - I do have an interest in functional programming (see below)!

Putting my own experiences aside for the now, the focus of this post is functional programming in industry. As an outsider with an interest in the community I often wonder why it is so small and how the situation can be improved. Everyone keeps going on about how beneficial functional programming is over imperative programming: faster development, shorter code, less bug prone and easier to test to name just a few.

So with all this power, where's the massive rush? Most of the successful languages of late have been successful mainly due to their success in industry. Java is a prime example. So a good way to become successful is for functional languages to attract the attention of industry. What's holding industry back though?

The problem I fear is a viscous circle that's difficult to slingshot out of. The number of FP programmers is very low. Because of this functional programmers are more likely to work in very small groups or even on their own on major projects. This trend seems to continue in industry, especially when there is a very small number of functional programmers in a company vying for the use of FP on some project within the company.

So we have come to the conclusion that FP groups in industry are very small or even solo. But how is this a problem? While the team works on the project all appears to be going very well. What happens when someone leaves though? Someone has to take over his section of the project. This is where the problems are hit! Finding a replacement is a mission in its own right. This is mainly caused by the lack of functional programmers, but also due to the next problem - programming style.

Why is programming style a problem? Well, this is an issue with imperative languages as well. Everyone has their own style of programming and when you have a large mass of code it can be very difficult for someone to take over without decent documentation. This is why many software development companies have very strict style guidelines such that all programmers follow and become quickly familiar with the same, well documented style.

Where are the style guidelines for functional languages?? This is the crux of an interesting discussion I had with someone at the ICFP Conference last week. All the above leads to this sad conclusion. Style guidelines are seriously underused by functional programmers. And this is one serious problem, because it takes so long for someone to take over a mass of code if it doesn't follow such guidelines. This might sound finicky, but it's true! In the conversation he gave a couple of examples such as one where it took a year to find a replacement Lisp programmer and a year for that replacement to understand the code enough to start maintaining it properly!

So I did a quick search for style guides for some common FP langauges and this is what I dug up:

• Haskell: This style guide comes with an automatic style checker. It appears to be rather rigorous, which is great!
• OCaml: This covers some aspects, but does not appear to be as thorough as the Haskell guide.
  
• Lisp: This is a fairly detailed style guide. It is still, however, in draft phase.
• Erlang: Appears to be lacking!!
  

So style guides do exist for the major functional languages. But how widely are the adopted? It's difficult for me to say as I'm not in the community, but my general impression is that functional programmers are the type of people that like their own style and stick to it. With such small teams this works in the short term, but fails miserably in the long term.

So, back to the beginning of this post. Why aren't people rushing to FP? There are these small success stories in industry, but not very many that have lasted over the long term. I believe that this vicious circle of functional programmers not wanting to let go of their favoured styles and change to a style guide is holding many people back from joining this elite community.

Is there anything that can be done to improve the situation? I believe that the community is too full of high quality programmers that the jump is just too far that most people within reach are also the type of people that far prefer following their own style. Gosh, even I prefer following my own style!

My functional programming experiences:

While I still cannot claim to be able to program in a functional language, the idea has fascinate me for some time. Ever since I've learned Python I have made use of several functional aspects it offers. And I love it! Earlier this year I started perusing through some OCaml tutorials, however the syntax really put me off it. I soon after started looking at Haskell. After sifting through some mediocre tutorials I finally settled on YAHT. I reached chapter 8 after I got sucked into other things that prevented me from progressing any further for some time. So I know a fair amount of the theoretical side of Haskell, although I've had next to zero practical experience.

ICFP Contest Losing It's Functional Nature?

When I first participated in the ICFP Contest last year I was expecting an AI problem from looking at previous years. I was attracted to the contest because of this. My team had won the Java Challenge (renamed the Parallel Challenge for that year) in the ACM ICPC the previous year, so I thought it would be nice to try out the longer version.

So I got a team together telling them to expect some AI. None of us knew any functional programming and although we could see from previous years that it was beneficial we weren't taking it seriously. We get the problem and boom, "code a VM". Ok, where's the AI? We immediately jumped in with C++ and even then we initially had efficiency problems, although those were quickly rectified. Everyone complained afterwards that functional languages lost out there.

Then the mini problems started revealing themselves one by one. I will admit we didn't get very far with them (mainly due to factors out of our control and a lack of interest from some who expected an AI problem). Some of the problems were slightly functional in nature, but I still don't think there was any major benefit in using a functional language.

After the lack of AI in 2006, I was able to gather some people into the team that previously wouldn't participate because of the AI nature in the past. This year we were far more prepared for a non-AI problem. I also got a larger team together after 2006 being multiple small problems. Once again, none of were functional programming gurus (although by now I have at least know a bit of Haskell).

We get the problem this year and once again it starts off with a VM (DNA->RNA). With most of our team being C++ fanatics, we quickly got it running and even discovered ropes pretty quickly. From reading other peoples comments, the functional languages suffered with the VM. Although it was possible to get an efficient VM, the sub-linear data structures appear to be fairly uncommon. Yes, they're not that common in C++ either, but the functional teams sure seemed to rush over to C++.

Then there were the problems once you've passed the VM. Our team used Perl, Python and a bit of Bash to glue the scripts together. I don't see how a functional language could have been beneficial in any way. Even if someone does find a way of using a functional language, I sure would like to see how functional languages can do a better job.

The idea of the ICFP Contest is to promote functional programming. Or at least, that used to be one of its goals. Has this emphasis changed? There sure still seem to be many teams whose primary tools are functional languages. Last year, none of the top three teams nominated a functional language as their primary tool. I'm confident the same will occur this year.

I certainly do not mean for this to be an attack on the contest. I still love it. This is just something that has been on my mind making me wonder what the connection to the ICFP is. Is it possible that the functional programming community can learn from the lack of results from functional teams and make the functional languages more powerful? Maybe that's the aim?