I was taken aback by the claim, mentioned by a speaker in an event I attended about two nights ago. The topic was about development in languages and concurrency, which particularly interested me. I don't know if you'll agree with the claim but I didn't and I guess the talk went downhill from there for me.

Anyway, what's all the fuss about functional programming languages? At first I thought "hey all languages are functional, that's why we have functions and procedures." Of course I was mistaken. I was actually referring to procedural programming. The type of programming that most of us know of (and love? or hate?!) is called imperative programming. We describe to the computer what to do, step by step. We are explicit in what we tell the computer to do. Well actually that was the first thing I liked about computer programming that's why I got into it. It kinda felt good to boss someone, er...I mean something around. Some weird kind of ego-trip huh?!

According to the wikipedia entry, functional programming is a way of specifying computation as the evaluation of functions and avoiding mutable state. In short, if your program changes values of variables, you are changing the state of the system. Why is this significant? Because when a computation does not have state, it can be evaluated in any order. Portions of it can even be evaluated in parallel. And we all know that the GHz wars are over, and the way forward for computing is to have multiple CPU cores. Our future CPUs will likely stay in the 3 to 4 GHz range, but they will have more and more CPU cores! Therefore parallelising computational tasks will become increasingly important. If we can learn to express our computational processes in a functional manner, an intelligent CPU or operating system can figure out how to parallelise those tasks, distribute them to the available CPU cores, and complete the tasks faster.

Microsoft actually introduced functional programming to C# not with C# 3.0 but with C# 2.0. Surprised? I actually learned that from Amil Reyes in a PHINUG event years back. He demonstrated how the List<T> generic class in C# allowed a bit of functional programming. Consider this example:

1. List<string> names = new List<string>();
2. // populate names here
3. List<string> namesStartingWithJ = new List<string>();
4. for (int i = 0; i < names.Count; i++) {
5.     if (names[ i ].ToUpper().StartsWith("J") {
6.         namesStartingWithJ.Add(names[ i ]);
7.     }
8. }

This is as imperative as imperative gets. Looking at the code, what do you think it is doing? Simple, it only harvests all items in the names collection that start with the letter "J" and puts them into the namesStartingWithJ collection. What makes it imperative? As you can see the programmer is pretty explicit; an index variable is defined to iterate from the starting numeric index of the array (0) to the maximum. And for each index it takes a look at the name corresponding to that index and looks if it starts with "J"; if so, the item is added to the collection.

C# allows a simpler construct: it allows us to do away with the numeric index, knowing that we are simply looking at each item in the names collection:

1. List<string> names = new List<string>();
2. // populate names here
3. List<string> namesStartingWithJ = new List<string>();
4. foreach (string name in names) {
5.     if (name.StartsWith("J")) {
6.         namesStartingWithJ.Add(name);
7.     }
8. }

So we eliminate the numeric index (and our dependency on the assumption that this collection exhibits array-like behaviour) with this approach. But it's still a step-by-step description of the task that the computer is to do. How do we make it functional? List<T> actually provides a "FindAll" method. The parameter to the FindAll method is a delegate or a function that takes in the generic type T (in our case T is a string) and returns a bool. If the bool is true, the item is added to an output collection; if false, it is not added to the collection. We utilise an anonymous delegate to do:

1. List<string> names = new List<string>();
2. // populate names here
3. List<string> namesStartingWithJ = names.FindAll(
4.    delegate(string name) { return name.StartsWith("J"); });

Look how concise this is. C# 3.0 simplifies it further by removing the "delegate" keyword and making the syntax even more concise:

1. List<string> names = new List<string>();
2. // populate names here
3. List<string> namesStartingWithJ = names.FindAll(name => name.StartsWith("J"));

So why is this significant? Are we simply trying to make programs shorter, or quicker to type? The significance of this functional approach is that we are not telling the computer step by step what to do. We only fed the FindAll method a means by which it can determine if an item from the names collection is to be added to the namesStartingWithJ collection. Regardless of the current state of the program, given a set of names, namesStartingWithJ will always resolve to the same value. This means that the order by which the items in the names collection are processed does not impact the result. That, in turn, means that an intelligent implementation of the List<T> class can choose to obtain those items in ANY order, maybe even PARALLELISE the retrieval of the names. And we end up with the SAME namesStartingWithJ result! Compare that with the imperative approach demonstrated in the first example -- can the system parallelise that? That is exactly why Microsoft is coming up with the PFX library.

Those who are learning foreign languages are usually advised by their teachers to learn to think in those languages so that they will be able to utilise them better. The same thing applies to computer languages. If all we know is imperative style programming using C-like languages, our programming approach will always look like C. I realised this about a decade ago when I was learning Perl; I saw that while my Perl code worked (for the most part) it looked like C littered with dollar signs. So as we all strive to learn this "new" (it's not so new, after all) approach of functional programming, let's do our best to think in functional ways. It's not easy, but it can be done.

So is SQL a functional language? I don't know. All I know is that it is NOT Turing-complete. I'll wholeheartedly agree if you say that SQL is a domain-specific language(DSL) though. I would have probably felt better during the talk if the speaker said that.