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!