In my last post I counted some words using F#, which turned out to require a single, simple line of F#. When I’d done the same thing before in C# i had iterated over the words and kept a count as I went, which is a typically imperative approach. So, I wondered if you could apply the functional approach to C# – perhaps using LINQ. Turns out you can.

Firstly, it’s helpful to have some words to count. Here’s a simple approach:

string test = "The cat sat on the mat.";

string[] words = test.Split(' ');

(In F# I populated a list of words directly, so there’s an extra line of C# here – largely because I started with my previous C# code.) Right, now to the counting in one line:

var result = from word in words

let strippedWord = StripPunctuation(word).ToLower()

where strippedWord.Length > 0

group word by strippedWord into grouped

select new { Word = grouped.Key, Count = grouped.Count() };

You may have noticed a call to StripPunctuation – a utility function I had in my previous C# code. Here it is (declared static as I was running it in a console application:

privatestaticstring StripPunctuation(string word)

{

string result = word;

if (result.Length > 0)

{

if (char.IsPunctuation(result[0]))

{

result = result.TrimStart(result[0]);

}

if (result.Length > 0)

{

if (char.IsPunctuation(result[result.Length - 1]))

{

result = result.TrimEnd(result[result.Length - 1]);

}

}

}

return result;

}

And now, with a little sprinkling of dynamic capability, outputting the results to the console:

foreach (dynamic entry in result)

{

Console.WriteLine("{0}\t{1}", entry.Word, entry.Count);

}

So it is possible to apply the more functional approach courtesy of LINQ, although there’s still more code than I had in F#. The C# is doing a couple of extra things (it strips out punctuation and is case insensitive) – but the point isn’t really the comparison between the two examples so much as the fact that by grasping some functional concepts can result in a change to your C# – which is a good reason to learn some F#.

For a recent MSDN Flash article I wrote some simple code to calculate word frequency in C#. As I get to grips with F#, I’m learning that the most rewarding but also the most difficult aspect is to think in a more functional way. To count words in an imperative style (as I did in my C# example) I would iterate through a collection of words and keep a running count. And, of course, you could write code in F# to do that. But what would be the point? How about approaching it in a different fashion? So, with those questions in mind, I fired up Visual Studio and went about trying to bend my brain into a more F# like shape. One of the things I like about F# is F# Interactive – a REPL which makes trying out and learning F# (as well as prototyping) easy – so that was where I started. First thing I needed to do was to create a list of words (since at this stage I’m concerned simply with calculating frequency and not reading files or strings.) It’s fairly simple to do that in F#:

let words = ["the"; "cat"; "sat"; "on"; "the"; "mat"];;

(the double semicolons are signal to F# Interactive the completion of a statement.) After reading a bit about processing sequences in F#, I spotted that there is a function to count elements in a list – it can easily be used against the whole list like this:

let count = words |> Seq.countBy(fun x -> x);;

The countBy function takes a function to generate a key – in this case we can use each individual word. To see if that has worked, we can print out the contents of the result:

After mentioning in my last post that my initial exposure to F# was negative, I’ve just had a similar reaction looking around the web. I think that’s because there’s two things to learn – the functional paradigm and a new syntax – and many of he posts out there assume that you’re familiar with at least one of the two. Which is why of the two books I mentioned before, I prefer Functional Programming – it gives examples in both C# and F#, which means you can separate the paradigm from the syntax and still learn about both.

My initial introduction to F# was effective. Unfortunately, the effect it had was to convince me that I should never learn F#. And so I stayed away from the language for a couple of years until its inclusion in Visual Studio 2010 reawakened my interest. I’m glad I’ve gone back to learning about F#, but it does make you realise that the first few minutes with a new language or technology are crucial.

So, this time around, I decided to go back to my tried and trusted method which consists simply of reading and experimenting. In support of which I bought a couple of books: Programming F# and Functional Programming. Other books are available. As for online resources, I tend to read articles that are suggested via the maelstrom of near real time social online noise-makers or search for relevant stuff. However, there’s a few links worth noting as good starting places:

A while ago I started a series of blog posts called Ruby Tuesday in attempt to get better acquainted with Ruby. Over time, I ended up spending more and more time with Python. And then .NET 4 introduced the DLR and the dynamic type to C#. It felt like I’d learned what I set out to learn and it was time to embark on learning another language. I’d been scared off F# in a presentation a few years ago, but I’m interested in languages that do things differently, that encourage me to think about problems in a different way so the curiosity remained alive. Functional programming offers a different approach from imperative programming and F# is a .NET Language – and a first class citizen in Visual Studio 2010. Decision made. I’ve started to learn a little about F# and recently wrote a short introduction to F# for the current edition of the MSDN newsletter, which prompted the thought that maybe I should start a series of F# posts to help me continue the journey. This is the initial post (and, who knows, quite possibly the last) in that series. Should be a fun ride.

Originally, I intended to read the data with IronPython. Reading CSV data with Python is very simple – there’s a built in CSV module. However, this module is written in C, which means it’s not available in IronPython – see here for more info. There is aproject called IronClad that allows Python modules written in C to be used from IronPython. At the moment, it’s built against .NET 2, which means that I could get it to work in .NET 2, but I had plans to use .NET 4 and the dynamic support in C#. Time for another approach.

Using the CsvReader class,it’s easy to access the data in a CSV file. I started with the Player Summaries sheet. To make this dynamic (and, therefore, useful for each of these sheets and, potentially, other as yet unknown sheets) I created a class to hold each row of data. Here it is:

By inheriting from DynamicObject, it will be possible to call this class dynamically – meaning that I can use the names of the data fields as defined properties on the class. Next I created a DataReader class that reads the data from the CSV file and stores it as an IEnumerable<DynamicDataObject>. Here’s that class:

There’s a couple of things worth pointing out. The first is that I’ve cleaned up the field names so that they can be used in code (by replacing spaces with underscores and removing anything in brackets). The second is that if a value is an integer, I’m storing it as an integer. I’m storing these values of type dynamic, which will come in handy when we want to query the data.

Speaking of querying that data, I wanted to use LINQ. Here’s some simple code I wrote in a console application to try it out:

By using the dynamic support in C#, the LINQ query just works and I can reference properties dynamically without having to create a class specifically for each sheet of data. It’s important in the LINQ query to declare the player of type dynamic – otherwise C# will revert to its statically typed ways and inform you that the Goals property doesn’t exist, which, given that it only exists at runtime, is correct. Now I can analyse the data easily. Doesn’t change the result though…

Earlier this year, Dr Dave and I worked on a Proof of Concept with Trader Media (probably most famous for Autotrader) and Fortune Cookie. You can read more about the project here. The application needed to be able to cope with being disconnected some of the time. Dr Dave and I took what we learned from this aspect of the project and wrote an article for MSDN Magazine, which you can read here.