Going Functional

Going Functional

No, I did not fall off the face of the Earth. I've been tied up pretty much in work and doing research and, and, and... Well before the year comes to an end I better add something to the blogging page.

 

My recent focus has been on getting to grips on functional programming. It's pretty much coming to a mainstream in the world of computing. The imperative style or paradigm (as they like to call it) of programming is slowly moving away from us. Languages as C++ and C# are in need for an extension that can accommodate the new functional language style. Actually, C# has already for more than a year (C# 2.0) added what is called LINQ (Language Integrated Query) and now is prepping for a final release of PLINQ (Parallel LINQ) and TPL (Task Parallel Library). All of this is for making a smooth transition to functional programming without leaving behind the tons of invested existing code behind - a smart move by Microsoft. Ideally it would be better to start over and have a language that is better suited for it, but there is really no choice but to add extensions to an existing language such as C#.

 

Functional programming is a very old concept. Remember the world of FORTRAN, LISP, HASKELL, OCAML? Well it's all coming back! Why? Although many inroads have been made in making programs more modular and thus manageable, we still run into trouble with complexity and "noise" for lack of a better description. The way to go is to take away features from a language instead of adding to it. This greatly simplifies the structure and the debugging process. The biggest reason really is because computers are going multi-core. You will very soon find it hard to buy a single-core computer. Yet, software does not really understand the multi-core advantage. It's been a free lunch so far in that the clock speed of processors kept gaining, automatically making programs faster and faster. Well, this will no longer be the case. Processors can no longer become faster (light speed is fixed) but be can add processors and do parallel processing. The only trouble is that programming as we have known it all these years is not very well suited for parallel / concurrent processing. However, functional programming is very well suited for concurrent tasks in that it does "parallel" better. Erlang is a pure functional language that really does "parallel" nicely by the use of message passing. It is thread-oriented and shares no memory. Shared memory is the culprit here. "Locking" is another way of managing shared memory amongst concurrent threads. Not to go way off course, the point I was trying to make is that with the advent of multi-core programmers need to change their habits.

A good place to start is C#'s LINQ that not only does database querying well (as I first thought) but also does a good job in doing general programming. Check out how one can write a complete ray tracer in LINQ here. Very impressive. Another good way to start is the upcoming new language called F#. It is the only real functional language for .Net at the moment. It is all at its beginning stages. Ride the functional language wave now!