Ever since the pundits predicted that the doomsday of Moore’s Law was fast approaching* (*debatable) . There’s  been an eerie feeling amongst the producer – consumer cycle of microprocessors. The question on everybody’s mind seems to be- So what is the consequence of this ? Does it mean that the microprocessor developers like Intel, AMD et al. would close their shop and get into other domains ? (for the love of God not another browser !)  Well the answer is astounding  NO.  Parallel computing, Multi core architectures were an indirect consequence of this.

As a co-consequence of this, something that was ignored for almost 60 years ago made it way back into  limelight and became a buzz word. Lo and behold for here cometh Functional Programming ! Ever since Parallel Programming, Multi Core architecture and Google’s Map Reduce came into the ZONE. Functional Programming is making sinusoidal waves all over the developer circuit. Functional Programming is as old as computers themselves and they rightly deserve all the credit people have been pouring all over it.

This is part 0 of an n part series – of my humble attempt in exploring the functional programming concepts using C#.

To understand the ‘F’ in Functional Programming, we need to step back a little and revisit the approaches we used to hitherto to solve a trivial problem say -  filtering a sequence of numbers to make it contain only odd numbers.

Procedural

In the grand old days of  procedural languages we would have probably written something like this.

void Main()
{
    List numbers = new List{1,2,3,4,5};
    result = FilterOnlyOddNumbers(numbers);
}

List FilterOnlyOddNumbers(List numbers)
{
    List result = new List();
    foreach(int n in numbers)
    {
       if(i%2 !=0)
       {
           result.Add(n);
       }
     }
    return result;
}

The problem with above code is every time I need a  new filtering logic, I would end up adding a new a method. Like the code below that filters out the even numbers.

List FilterOnlyEvenNumbers(List numbers)
{
	List result = new List();
	foreach(int n in numbers)
 	{
 		if(i%2==0)
 		{
 			result.Add(n);
 		}
 	}
 	return result;
}

And what is hard to miss from the above code is that the only change between FilterOnlyOddNumbers and FilterOnlyEvenNumbers is the line #6 !!

Object Oriented

Enter Object Oriented paradigm – a paradigm that promised to cure us from the above problem of code redundancy using Abstraction..!!

And here’s what an object oriented junkie would have done with the problem of filtering numbers. Abstract out the logic for filtering the numbers to an interface IPredicate

(line #6 of the earlier code segments)

interface IPredicate
{
	bool FilterCondition(int n);
}

And we would rewrite our Filtering method to use the abstraction provided by the interface IPredicate

List FilterNums(List numbers,IPredicate p)
{
	List result = new List();
	foreach(int n in numbers)
 	{
 		if(p.FilterCondtion(n))
 		{
 			result.Add(n);
 		}
 	}
 	return result;
}

Notice how line 6 checks for the predicate of the filter condition. To use the FilterNums method we would need to create classes which implement the IPredicate interface. And Yes. this is the Strategy design pattern !

class OddFilter:IPredicate
{
	public bool FilterCondtion(int n)
	{
		return n%2!=0;
	}
}

class EvenFilter:IPredicate
{
	public bool FilterCondition(int n)
	{
		return n%2==0;
	}
}

And invoking the FilterNums using poor man’s dependency injection.

List oddNums  = FilterNums(ints,new OddFilter());
List evenNums = FilterNums(ints,new EvenFilter());

Ah Sweet ! Before this design inflates your object-oriented design purist ego and you start grinning ear to ear. Lets look at the shortcomings of this OO design.

In an OO universe everything is an object. If you look carefully at our OO design above, all we need is a predicate FilterCondition to achieve a trivial filtering function but we’re forced to abstract it into an interface and implementing the interface in a Filter subclass. And what’s worth noticing further, is that you would require as many  filter classes implementing the interface, each containing a just a couple of lines of code.  Better fix that before the class proliferation police come knocking at your door.

To draw a trivial analogy – consider the class OddFilter as a box which contains method FilterCondition – the ball inside the box OddFilter, whenever an Oddfilter is passed between functions, it is passed as boxes (objects) to and fro between functions. In short the boxes are the objects and member methods are the balls in the boxes.

With respect to our FilterNums method - FilterNums receives the OddFilter object (box) and then unpacks the box (references to the method) to find the ball (FilterConditon method).  Looking closely we find that all we truly need is the ball (method) but we are over engineering the design by packing the ball into the box (object).  But wait a minute I cannot just throw a ball alone (method) between function calling boundaries because *my programming language* is object oriented everything which goes in and comes out of the function are objects !! *my programming language* only knows to throw and catch boxes !!

Or is it ?? :)

Functional Programming

One of the core concepts of Functional Programming is that all your functions in your programs are First Class functions. Err.. Well OK that sounds cool but what on God’s green earth is a First Class Function ?

It just means that Functions in the language gets same First Class treatment like the objects – meaning you can throw and receive just the functions between a function calling boundary without wrapping them in objects.

With respect to our earlier analogy we can just throw around just the ball between the methods with out unnecessarily packing them into boxes!

In C#, this is achieved using delegates and lambda expressions.

And rewriting our FilterNums method using Predicate<int> delegate

List FilterNums(List ints,Predicate Filter)
{
	List result = new List();
	foreach (int n in ints)
	{
		if(Filter(n))
		{
			result.Add(n);
		}
	}
	return result;
}

And invoking the FilterNums method is easy and elegant. And you do not have to create additional classes for each of  additional filter logic.

List oddTodds = FilterNums(ints,i => i %2!=0);
List evenStevens = FilterNums(ints,i=> i %2==0);

The FilterNums takes a first class function (Filter) as a parameter. Such functions that take in a functions as parameters or/and whose return types are functions are called as Higher Order Functions.

Now that you know the definitions and meanings of First Class functions and Higher Order functions you can now speak to a Haskell programmer.

This concludes Part 0 of this series, In the next post we’ll look at currying of a function and before I forget – you can you leave your chef’s hat at home :)

If you are a neo .NET programmer, one of the tools in your arsenal would have been the .NET Reflector. A very powerful .NET decompiler that has been answering a lot of our questions about what exactly happens behind the curtain.

It so happens that Red Gate the company that took over the development of the tool from Lutz Roeder has announced that that tool will no longer be free. And Yes, No longer ”Free” as in Free Beer. It never was “Free” as in Free Speech! The true rationale behind this move might be something we would never know..

And if you had the older free version of Red Gate Reflector- it would run for until June 2011.

Here are the possible alternatives

Get Red Gate’s Reflector

• Pay $35 USD and get the license
• Troll on Red Gate’s Forum – Convince them to Roll Back their decision (belive me a lot of them are already on it)

If you want to be unforgiving towards Red Gate here are the alternatives

• Team Up with a couple of devs and roll out your own .NET Decomplier like this wonderful team is doing http://wiki.sharpdevelop.net/ilspy.ashx . We have nothing but praise for rolling out the basic functionality  out of the window with in couple of weeks. Fork them on github and may be contribute a feature.
• Buy Jetbrains Resharper 6 – EAP Available ! Download the nightly builds from JetBrains Confluence Site.

But I want leave you with a positive note.

JetBrains has announced that the would develop (read it as GIFT) a Free Stand Alone Decomplier to the community! To fill the void that has been left by Reflector.  And this time “Free” as in Free Beer.

Request: Stop reading this right now and show your gratitude to Jetbrains. Leave a Thank You note here if you haven’t already.

Update: Jetbrains is looking for a name for this new standalone .NET Decompiler. If you have a prospective name for this new tool, let Jetbrains know by posting it on their facebook page there are 5 licences up for grabs if your name makes the cut.

And, I will post a deep dive of this new tool once it’s out.

Again, Thank Jetbrains for their work :) A simple Thank You often goes a long way.

Update 2: The new decompiler by jetbrains is called dotpeek. It’s not out in the wild just as yet. But you can follow @dotpeek to keep yourself posted.

Update 3: Telerik has just launched a free decompiling tool called JustDecompile you can download the beta from here

Update 4: JetBrains decompiler dotpeek available as EAP download it from here.  And here’s the introduction to the tool.

Pretty much all my agile-aware developer life I have been using Rhino.Mocks to mock interfaces. I had never landed myself in a position where I had to mock a concrete class. Being a Design Purist (well , at least when I review code), I never liked the idea behind mocking  a concrete class. The idea or the application of such a mock object is rare. But I wanted to experiment to find out whether such a thing is possible. This is the experiment !

Consider a concrete class MyAdder, which I would like to mock. It’s a utility class which can get as trivial as it can. Which would return a sum of two integers x & y.

namespace MyMathLibrary
{
    public class MyAdder
    {
        public int Add(int x, int y)
        {
            return x + y;
        }
    }
}

A trivial unit test for testing the Add method above using Mocking would look something like this.

namespace MyMathLibrary.UnitTest
{
using NUnit.Framework;
using Rhino.Mocks;

	[TestFixture]
	public class MyAdderTest
	{
		[Test]
		public void AddTest()
		{
			MockRepository mockery = new MockRepository();

			MyAdder mockAdder = mockery.StrictMock();
			// use mockery.CreateMock<> for older versions.
			Expect.On(mockAdder).Call(mockAdder.Add(2, 3));
			// Return int 5 for all calls..
			LastCall.IgnoreArguments().Return(5).Repeat.Any();
			mockery.ReplayAll();

			int sum = mockAdder.Add(1, 3);
			int sum2 = mockAdder.Add(4,3);
			Assert.AreEqual(5,sum);
			Assert.AreEqual(5,sum2);
		}
	}
}

Snap ! – the test fails and throws a System.InvalidOperationException

System.InvalidOperationException: There is no matching last call on this object.
Are you sure that the last call was a virtual or interface method call?

at Rhino.Mocks.Impl.RecordMockState.GetLastMethodOptions()
at Rhino.Mocks.MockRepository.LastMethodCall(Object mockedInstance)
at Rhino.Mocks.Impl.CreateMethodExpectation.Call(T ignored)
at MyMathLibrary.UnitTest.MyAdderTest.AddTest()

in MyAdderTest.cs: line 18

If you still haven’t figured out, the error. This is because, methods that you would mock from the concrete class should be marked with virtual.And unlike Java by default every method is non virtual. This is a drawback of mocking concrete classes & this is something you will have to live with.

Here’s the new MyAdder class with the magic & voodoo to run the test cases.

namespace MyMathLibrary
{
    public class MyAdder
    {
        public virtual int Add(int x, int y)
        {
            return x + y;
        }
    }
}