Showing posts with label Functional Programming. Show all posts
Showing posts with label Functional Programming. Show all posts

Wednesday, March 25, 2009

First hand experience with FP

Three years ago, yes i think it's been 3-4 years since dipping my fingers in the world of Functional Programming. Although XSLT is not a functional language but it strives to follow the FP guidelines and it is the weapon that I hold responsible for my First (FP) Blood.

I started using XSLT in .net, producing result sets in XML and writing XSLs for the visually appealing transformations. First it was simple if-else, for-each, using XQuery etc. but as soon as I stumbled upon variable assignment, I thought I caught a bug in XSLT, "I cannot reassign a variable, what's the use of the VARYiable then?"

Then I tried writing a for loop from a to b, I was troubled again. Soon I realized there was something different going on here and I would have to learn it properly before calling XSLT my preferred transformation language. At that time I read about functional language, which uptil then I thought was another name for procedural language. Satisfied, I went ahead with XSLT using recursion, template calling etc. techniques that were already taught to me but as an alternative to normal programming construct and not as a measure to make out of reassignment restrictions.

After that I forgot about FP and went on with life, rejoicing references, reassignments, reflection and then I heard about closures (around a year and a half ago) and people talking about forcing it somehow in the beautiful, simple, verbose Java language. At that time, I could not get a hang of it and went on with life. Then came the Scala buzz, I was always a great advocate of static typing and Scala being termed as the 'statically typed dynamic language' attracted me. After some days of learning I came to know about the FP fundamentals, side-effects, currying, closures etc. aside from being refreshing, these concepts enabled me to realize the modularization of functional behavior, an essential requirement in a good design that no OOP design pattern has been able to solve in a concise manner.