More Functional Programming Tippytoeage

In the last entry, I wrote about an interesting discovery I made as I began to learn more about functional programming. In the first chapter of a book about the Ocaml language, I found a few lines the emphasized the ease and power of being able to supply functions as parameters to other functions (see code in last entry). I also mentioned how it was a little more cumbersome to implement in a language like C#, but not impossible. I didn't share that code, though, because I am a code tease. (Note: that's coDE tease. I don't want any getting the wrong impression.)

Can you pass in functions as parameters in C#? Sure you can, using delegates. In fact, when it comes to passing around these functions using delegates, the functions don't even have to be actual, named functions. (That's thanks to a new feature in C# 2.0, anonymous methods.) While you can definitely implement the same functional in C#, it looks a lot different.

public delegate T mydelegate(T x);

public static void Main()
{
    mydelegate successor = delegate(int x) {return x + 1;};
    mydelegate square = delegate(int x) {return x * x;};

    Console.WriteLine(Compose(square, successor, 5));
}

public static T Compose(mydelegate method1, mydelegate method2, T x)
{
    return method1(method2(x));
}

The code I just presented is the functional equivalent of the code presented in the last entry. Regardless of your expertise with either language, which one is easier to understand? Which would you rather write?

I'm a total C# dork, but I must say that I find the Ocaml/F# code easier to understand. Look how succint it is. Notice how it never once mentions anything about generics, or even data types. We don't need to create or understand a construct like a delegate in order to pass our functions around; we just pass them. That's very nice.

Tippytoeing into Functional Programming

Like a lot of other people, I've been dipping my toes into functional programming lately. This is for three reasons. First, I've read a lot about the new language features in C# 3.0, and a lot of them are rooted in fp (check out LINQ for references). Second, about a year ago, I wrote a gigantic amount of number-crunching code that had some really nasty state issues. Third, a gang of roving Lisp hooligans shang-haied me on 6th Street and tattooed a lambda on my forehead; in case anyone asks, I should at least know the lingo.

I don't know if y'all have been following it, but Microsoft Research released a really interesting functional language recently, F#. It runs on the .NET framework and it has Visual Studio support, both of which lessen the scariness factor for wimps like me. And so, I'm learning F#. Actually, I'm not sure that I can call this learning yet; the process thus far has been like handing the abominable snowman a fax machine manual. However, again like the abominable snowman, I am resourceful and tenacious, so I haven't given up.

F# is very similar to OCaml, or so they tell me. I found F#'s documentation to be a little cryptic, and I discovered that it's a lot easier to read OCaml docs and port those concepts to F#. For some good OCaml reads (a phrase not often heard), check out the online translation of Developing applications with Objective Caml.

Even in Chapter 1's throwaway sample code, I found something that validated my reasons to learn more about functional programming. (All of the following code works in F# and should work in OCaml if you replace the Console.WriteLine part, although I honestly haven't tried compiling anything in OCaml. I've got to draw a line at the nerdiness somewhere.) I've built on the example a little bit to make it easier to understand.

First, we define a couple of functions, square and successor.

let successor x = x+1 ;;
let square x = x*x ;;

Okay, that's simple. When given an integer, successor gives you the next one. Square just squares a number. Now we do some functional magic.

let compose f g x = f(g x) ;;
System.Console.WriteLine("The successor to 5's square is " + (compose square successor 5).ToString());

The Compose function just lets us chain two functions together simply. With it, we call a function to increment successor by 1, then we call the square of that method. Couldn't you do that with square(successor(5)) in any normal language? You could, but that would ruin this whole post. Also, it'd miss the cool part of Compose, which is how easy it is to supply a function as a parameter to another function.

Now, you could most certainly implement the exact same functionality in C# using delegates. I've done just this, and let me tell you, it contains 10% of the elegant with 1000% of the confusion. In the next post, I'll share that code. I may also furnish some smores, we'll see how I'm feeling.

I'm an idiot when it comes to functional programming, but it's only taken me a few pages of a book to see why it offers such a compelling alternative to imperative programming. Through a little comparison, you may agree. If not, well, at least you're not paying for any of this information.