October 7, 2008

A Voyage to Functional Programming in F#

I have been programming for more than twenty years. Starting from BASIC in Apple II and CP/M, I am now working on VB.NET for most of the time in my job.

I had learned C and then C++ more than ten years ago. I found object-oriented programming great as it delivered a more power and productive paradigm. But in recent years, I realized that object-oriented programming in certain sense is merely an evolution from the imperative/procedural programming paradigm.

OOP definitely enables us to handle a higher level of complexity than plain procedural languages. Encapsulation, inheritance and polymorphism are powerful tools that I used all the time. I especially keen on building libraries to boost the performance of my team. In fact, I had built a few frameworks: one for C++ and at least two others for VB and VB.NET

However, under the hood, inside the library, everything is still so mechanical and in certain sense, low level. I tried hard to encapsulate boring logics (like copying values from screen controls to a database record and vice versa) to make building a business application more interesting (well, at least not boring) but I found that it is still a huge effort to build a full fledge application. Even with a powerful IDE like Microsoft Visual Studio, I found we still have a lot to do in order to deliver a solid application for my end-users.

We simply need more productivity and more important is to reduce the complexity in the deliverable as we need to maintain them afterward.

So I started a research on what other alternatives do we have.

Java simply is not what I am looking for as from my point of view, VB.NET/.NET Framework and Java are just the same thing from different vendors. Personally I think C# is a better choice than Java (there are free implementations of C# in various platforms) as at least I have a very powerful IDE.

I took a look in several (radically different) alternatives including Smalltalk and LISP. Smalltalk is probably the mother of all OOPs. People said that Smalltalk is productive and modern OOP languages still cannot fully mimic it. It is succinct and terse. I had tried to download one implementation to take a look. It looks quit special that it doesn't like the programming languages we use before (where source codes are plain text files). It presents in term of something like a virtual machine image.

A poor analogy is MS Access. You get everything inside a mdb file. When you quit, you dump the executing environment into a file.

Personally the Smalltalk environment is not appealing to me. I don't like the UI very much. It doesn't look native in any platform including Mac and Windows.

Smalltalk definitely is a neat and compact language that worth for further study in order to understand the origin of OOP better.

I had also realized that a powerful language still requires a comprehensive library. Smalltalk does have a huge library. But I need to invest a lot of time to learn a completely different library.
In addition, we need a solid database back-end for keeping persistent data. Smalltalk has its own way to handle persistence but it is not the mainstream way (client/server).

I peered some information on LISP but I am scared by the parentheses (even I am a C/C++ programmer as well). LISP is also a terse programming language but I think it is too difficult and the programs are simply not legible to most people.

Finally I settled on F#. Both LISP and F# are belong to functional programming (FP) paradigm.

Functional programming is a complete different paradigm from imperative (and OO) programming.

I found it terse as well yet I can understand it (though some of the concepts are new to me).

The advantage is it can use .NET Framework. Thus it gives me a break from OOP and yet taps the power from the familiar .NET Framework.

Therefore I decided to dive into it to seem whether functional programming can deliver its claims in terms of productivity and expression power.

I would like to share my findings in this blog to those interested in learning functional programming.

No comments: