Federal Linux

Functional Programming

Tracy R Reed  | 

Lately, in addition to learning more about python I have been doing a lot of reading about functional programming (as opposed to imperative programming).

I have talked with some of you about this in recent meetings. It used to be that hardware was too slow to support functional programming or really any high level language. LISP was the first functional and high level language to be used. LISP was conceived of in 1956 and fully implemented and useful by 1962. The performance of LISP on the hardware of the day seems to have given the whole class of languages a bad name and doomed them to obscurity. Other than AI research and some universities, almost everyone dumped LISP for C and similar languages. But the benefits of this method of programming combined with much faster hardware which renders the overhead of high level languages irrelevant seems to be causing a comeback. I think it is time to take another look at functional programming and many people seem to be doing so. The amount of functional programming activity in the FOSS world these days is pretty impressive. It is definitely a different way of thinking about programming so it will take some getting used to.

Functional programming in general has appeal for a number of reasons.

The first is that it is primarily based upon the mathematical idea of a function. As computers are inherently logical/mathematical devices I find this appealing. Specifically it involves lambda calculus and the idea that you can implement the equivalent of Turing complete functionality using the composition of functions.

They are functions in the sense that they always produce the same and only one output for a given input, just like the mathematical definition of a function.

There are no side-affects which can make your programs non-deterministic and hard to debug. You never say things like a=b. Instead you evaluate a function which returns b whenever you would have otherwise used a. But even this does not really explain it properly. You will have to do some reading on your own to get it. The book “The Little Schemer” is a pretty good introduction to the theory of functional programming. It is mind bending and enlightening at the same time. Having finished that book I am now slowly working my way through “Simply Scheme” after which I hope to tackle “The Structure and Interpretation of Computer Programs”. Once done with all of that I should have a pretty solid grounding in functional programming in Scheme and be able to take on other functional programming languages.

These ideas together mean you get code that is much more likely to do what you intended and only what you intended which makes it great for mission-critical applications which require stability and high availability. They also mean it is closer to being possible to mathematically prove the correctness of your programs. You still can’t actually prove it for anything but the simplest of programs but it gets us closer and I think that is a worthy goal.

With functional programming you describe the problem itself rather than an implementation of the problem and the computer works the rest out for you. I find this pretty amazing. And because of this programs written in a functional language tend to be much shorter. A program written in an imperative programming language tends to be 5-10 times the length. Less code means less opportunities for bugs and debugging.

With cpu’s getting faster and getting wider in terms of parallelism due to multi-core designs functional programming is in a prime position to take full advantage of the capabilites of the new cpu’s. Parallelizing a functional program is easy because the nesting of the functions clearly delineates what depends on something else and which things can be run safely in parallel.

I have been reading about Lisp, Scheme, Haskell, and Erlang. Note that Lisp is not a “purely functional” language in that you can also do imperative programming with it. But the rest are purely functional. Some day I am going to have to pick one for serious learning. As I mentioned, I have a few books on Scheme already so it is in the lead. But the succinctness and mathematical foundations of Haskell are appealing. I just recently began learning about Erlang. Erlang was written originally created by Ericsson and they use it on their phone switches and other devices that need high reliability. It seems to have the advantages of Haskell plus it has very strong concurrency support (threads done in a safe and sane way: no locks or shared memory, only message passing), has an emphasis on highly reliable code, you can patch it on the fly without stopping the program (nice for upgrading those switches that require 5 9’s of uptime), can be used to do distributed programming in a transparent way, and has built in support for a distributed database called Mnesia. That is pretty much all I know about it so far, haven’t written any code yet. But I look forward to trying it out. We really do have an embarrassment of riches when it comes to programming languages.

I never really appreciated the value of RSS until I got the Sage plugin for Firefox. Now I get a very useful feed of info from a number of good sites. One of these sites is: http://lambda-the-ultimate.org which always has lots of very good discussion on functional programming and language design. I found out about Erlang through this site. Check out http://lambda-the-ultimate.org/node/197 which has direct download and torrent links to “Erlang The Movie”. They demonstrate some rather neat features of the language. The video itself, made in 1990, reminds me of an episode of Fawlty Towers or Are You Being Served? Watch it and I think you will see why. :)

Hello Joe. Hello Mike. Hello Mike. Hello Robert. Hello Joe, Hello Mike. Hello.”

I am working on a wiki page with lots of links to functional programming resources. I will post a link to it when I have it a little further along. I will post some functional programming examples here eventually also.