How to get pragmatists to use F#

Don’t talk about monads and other tips for evangelists

I recently read Eric Sink’s article on Why your F# evangelism isn’t working It’s a great article and anyone who cares about introducing better tools and languages or anyone who wants to know why a language gets popular should read it. But one of the things he doesn’t spend a lot of time on is how to identify and convince a “pragmatist in pain” to adopt F#. This isn’t a lapse in the article because it was not the main point however it was something that beared exploring

I recently had a case to use F# at work. Convincing the other pragmatists to use F# was surprisingly easy. Some of that was the open-mindedness of my coworkers. But it was also helped by how we ‘sold’ it to them.

1. Don’t emphasize the differences

When introducing F#, or any new technology, developers have a tendency to emphasize how mind-blowingly awesome and better it is than what everyone else is currently using.In the case of F# evangelists normally say how much better it is than C#.

Don’t do this

F# may be a better language than C#, I certainly think so. But saying that makes people defensive. Which makes them less likely to be open minded.

That’s not how you sell a pragmatist on F#. You sell them on it by emphasizing how much easier/faster/cheaper it will make their projects, how easily it works in the .NET stack and how easy it is for C# programmers to pick up.

The first rule of evangelizing functional programming is, you don’t talk about monads

As great as monads are all most pragmatists have heard is that they are confusing and hard. In general if your evangelizing something those aren’t traits you want to emphasize. By not introducing the more complicated things at first you get a gradual learning curve, which gets you more buy in.

A good example of doing it the right way is Jon Skeet and Tomas Petricek’s book “Real World Functional Programming” it introduces F# and functional programming by showing how similar functionality would be written in C#. It doesn’t even introduce monads until 340 pages into the book.By that point in the book the reader is already comfortable with functional programming so the new feature is less daunting.

As a side note the entire book is full of great examples on how and why to write functional code. It has the added “brand recognition” of being co-authored by Jon Skeet so most C# programmers will respect it. If you are trying to introduce F#/functional programming to an experienced C# programmer it’s a good place to start

2. Make sure the project is self contained and small

The problem we decided to tackle was parsing, processing and converting a CSV file that we got from a 3rd party vendor. This has the advantage of being fully self contained. So we didn’t need to interact with any of our existing C# code.

Although F# (and I assume Scala) both have the advantage of playing nicely with more mainstream languages, interacting with other languages and their idioms is never seamless. If you’re trying to get a pragmatist to try out or adopt F# you want it to be as painless as possible. So you want to make sure it’s self contained.

Semi-relatedly make sure it’s a small project. Pragmatists know that adopting a new language is risky. You want to start with a small project because the small scope gives the pragmatist confidence that if your new language doesn’t live up to the hype they can quickly go back and rewrite it in a more ‘conventional’ language. In this case the project only took about a day and a half. However if we had written it in C# the source code would have been 4–5 times longer. Which leads me to my next point

3. Make sure the problem is one F# is preposterously better at

If you are trying to get a pragmatist to adopt your language you want it to shine. In this case I was parsing a CSV file that contained the results of a survey. FSharp.Data has the CsvProvider tool which handled parsing the file. It lets you work with the data in the CSV file in a statically typed way. It takes the header row and generates a type with those properties, automatically.

In addition to that library F# as a language supports discriminate unions which are conveniently the best way of representing survey answers. If the question is “What type of pet do you have?” the best way to represent the space of possible answers

type Pet =
 | Dog
 | Cat
 | Camel
 | Snake
 | Other string

In addition since all the questions were optional the answers were of type

Pet option 

Instead of Pet. Using Seq.Choose along with pattern matching allowed us to easily group the surveys based off of their (optional) answer to that question. These features let us iterate on the project quickly while writing less code than the C# solution

Overall the project went well early adopters were excited that we were using F# and pragmatists were happy that the problem was solved. It was successful because the project was small, suited for F# and didn’t depart to radically from code people were comfortable with.