Professional F# 2.0

Oct 11

Advice for Getting Started with F#

I had a great time at NYC Code Camp this last weekend. About half the people in my talk already knew F# and were there to talk about Type Providers, the other half just came to see what this F# thing was all about. This post is to help those in the second half begin their F# learning adventure.

The first thing anyone who is looking to get started with F# should do is work through the tutorial examples on Getting some hands-on time with the basics is extremely important, especially if you haven’t done much functional programming before.

Once you’ve got the basics down, the next step is thinking through some real problems in F#. For me, this was writing an Ant Colony simulation. With the version linked to here you can actually compile and then try your own ant behavior code against mine! Other great options include the Coding Dojo Katas or Project Euler (for the mathematically inclined).

It’s best if you do most of your play using .fsx files and F# interactive at first. Just highlighting code and hitting Alt-Enter makes the process of learning so much faster. However, if you insist on working with unit tests I suggest Xunit as it doesn’t require the use of classes for hosting your tests.

At first it’s also best to ignore most of F#’s features, it can be overwhelming otherwise. Try your best to focus on comprehensions. These may not always be the best way to solve a problem, but they allow you to write very imperative code right in the middle of a bunch of functional stuff and so are kind of an escape hatch for when you don’t know how to do what you want functionally. Eventually you’ll want to move on to recursion and folding though. When you’re ready to make the jump read this post which talks about how to go about it.

As you’re playing with F#, don’t be afraid to look things up along the way when you get stuck. There’s quite a few good resources around for F# including the F# Programming WikiBook, the code samples provided by the F# team, and a number of print books including Professional F# 2.0 (shameless plug). When all else fails the MSDN documentation for F# is actually very good!

I can say from experience that at first you will likely experience quite a few syntax errors. Don’t worry too much about it, your brain needs to build up a model of how the types and syntax work. Once you’ve gotten over that hurdle I promise you’ll be amazed by how different the programming world looks.

Nov 10

An F# Whirlwind

Just under two weeks ago I was packing up my things at Atalasoft and enjoying my last Friday Beer:30 with coworkers and friends.

Moments before I left Atalasoft to seek fame and fortune.

My last Beer-30 at Atalasoft

A lot has changed in these past two weeks. I’ve moved into my Hoboken apartment and (partially) assembled a whole set of IKEA furniture, I’ve gotten started as the first employee at a brand new company called Bayard Rock, and I’ve seen quite a few exciting things happen in my own little F# world.

First, I’ve managed to get a new site up for my F# Discoveries This Week blog series. It’s called F# Central and I hope to do big things with it far beyond the scope of my weekly blog post. Stay tuned.

Second, after a year of blood, sweat and tears Professional F# 2.0 has been released.  I wrote the entirety of Part 3 and worked hard to convey every moment of functional programming epiphany that I experienced while learning F#.  I hope you’ll pick up a copy and let me know what you think.

Third, this Friday I’ll have the great honor of speaking alongside giants such as Don Syme, Tomas Petricek, Judith Bishop, Joe Pamer, and Howard Mansell at the F# in Education workshop. In my talk entitled F# in the classroom and the lab, I’ll be drawing on my own past experiences in order to paint a picture of how F# can be used to improve all aspects of academic life.  Even if you can’t make it in person be sure to watch it via the internet simulcast.

Finally, with the help of my good friends Rachel Appel and Howard Mansell I’ve got everything in place for the first meeting of the New York F# User Group.  I’m getting the feeling that the NYC F# community is about to explode and I hope you’ll be part of it.  Come join us if you’re in the area and help spread the word if you aren’t.

Apr 10

The Ted Neward F# Folding Challenge

My friend, and fellow Professional F# 2.0 author, Ted Neward recently challenged me to a bit of a Code Kata.   Take a list of numbers and compress it in a particular simple way but without any mutable state.  What makes this problem interesting is that a tech interviewer mentioned that that he hadn’t seen a functional solution to this problem.  I also wanted to share this because I think it’s a great example of how to convert an imperative loop into a functional fold.

So, on to the problem.

Given a set of numbers like [4; 5; 5; 5; 3; 3], compress it to be an alternating list of  counts and numbers.

For example, the solution for [4; 5; 5; 5; 3; 3] would be [1; 4; 3; 5; 2; 3], as the list consists of one four, then three fives and finally two threes.  Ordering counts as the initial list must be reconstructable from the compressed list.  The answer to [4; 5; 4] would be [1; 4; 1; 5; 1; 4]

The imperative solution is rather simple, we use three variables outside of a loop:  a last value, a count and an accumulator list.

let clImp list =
    let mutable value = 0
    let mutable count = 0
    let output = new System.Collections.Generic.List<_>()
    for element in list do
        if element <> value && count > 0 then
            count <- 0
        value <- element
        count <- count + 1
    if count > 0 then

Using the normal .NET mutable list type, this version works efficiently and produces the output we expect.

> let compressed = clImp numbers
   Seq.iter (fun e -> printf "%i " e) compressed;;

1 4 3 5 2 3

How might we convert this to a functional style?  In this example, the general type of operation could be thought of as the gradual building of a data structure while walking over a list.  F# just happens to have a list processing function designed just for this task.  This function is named fold and it is one of the most useful constructs in any functional programmer’s tool chest.

let clFold input =
    let (count, value, output) =
            (fun (count, value, output) element ->
                if element <> value && count > 0 then
                    1, element, output @ [count; value]
                    count + 1, element, output)
            (0 , 0, [])
    output @ [count; value]

Here, we are doing almost exactly the same thing as in the imperative version but with a fold instead of a loop.   The secret is that instead of putting variables outside of our loop and changing them with mutation, we have added them as elements in our accumulator tuple.  In this way, the values are updated when each element is visited with no mutation.

However, there is one serious problem with this example.  Appending to the end of a linked list requires recreating every node in that list.  This will make our algorithm grow exponentially slower approximately in proportion to the length of the input list.  To correct this we have two choices: do a head append with a normal fold and reverse the list when we are done, or use foldBack.  The foldBack version is a rather small step from here and looks much nicer, so let’s go in that direction.

let clFoldBack input =
    let (count, value, output) =
            (fun element (count, value, output) ->
                if element <> value && count > 0 then
                    1, element, [count; value] @ output
                    count + 1, element, output)
            (0, 0, [])
    [count; value] @ output

There are only two real changes here.  First, we are using foldBack instead of fold.  This change causes some argument reordering.  Second, we are appending to the head of the output list instead of the tail.  It works well, is rather fast and is easy to understand if you are comfortable with folds.

However, there is a bit of a dirty secret here.  Under the hood foldBack converts its input list into an array when the size is large.  As arrays have linear element look up time, they can be walked through backwards very quickly.  Does this make the solution not functional?  You’d never know unless you looked at the underlying implementation.  Anyway, however  you want to label it,  it sure works well.

If you liked this example and want to see more check out our book, Professional F# 2.0.   It’s just about to be done.  In fact, I better get back to editing.

Feb 10

Professional F# 2.0 in Progress

Over the past few months I’ve been hard at work on Professional F# 2.0 for Wrox.

Describing functional programming to an object oriented audience is a major challenge but I believe I have risen to it well thus far.  The main issue stems from the fact that functional programming is so different and most of the ideas encompassed by it are difficult to extract alone.  I know it took a lot of “A-hah!” moments before I really understood even the basic underlying paradigm.  The goal now is to make the idea gained in each of those moments explicit, at least in the context of the F# language.

Well, time to get back to business.