Adopting F# in a C# Shop

I have been speaking to different groups in both large and small companies about adopting FSharp as part of their .NET stack and the resistance ranges from the understandable to the head-scratching.  I posted a similar question to the Google group here and got some pretty interesting responses.  The funniest was this video.  Scott Wlaschin offers several convincing reasons to use FSharp here  as well as  several ways to try and work around the walls thrown up in a “C Sharp shop” here.

I have recently implemented a project using FSharp in a large insurance company that is a  “CSharp shop” using the following technique and hopefully someone else can get some use out of it.  My first premise is that FSharp is not the end, it is the means.  Therefore, you don’t want to walk into any meeting and say something like “hey, I heard of this great new language, we should try it out.”  That kind of statement will be dead in the water with the layers of project managers, architectural review committees, etc….  Rather, you need to walk into the meeting and way “As you know, our company is supposed to be ‘innovative’ and I have been experimenting outside of work with different ways to reduce the number of bugs in our code and deliver software faster.”

(Jamie note, since I wrote this, this study came out pointing out that functional programming does produce better code quality.  However, its benefits are not as important as having a high performing team with the appropriate process (team size, project size, and commit size)).  One more thing to mention to the PM.

The next step is to realize that one of the most overlooked benefits of FSharp is that since it is a .NET language, you can slide a FSharp project into a Visual Studio Solution with just a couple of button clicks and the existing CSharp code will just work with it.  Use this to your advantage by creating an interface to an existing CSharp class that has some conditional logic.  For example,CSharp implementation of a class that creats a customer for an order

1 public class CustomerCreator 2 { 3 Boolean alreadyHasAnAccount = false; 4 5 public Customer CreateCustomerForAnOrder(Order order, String firstName, String lastName) 6 { 7 //Actual implementation is not important 8 return new Customer(); 9 } 10 }


The actual implementation is not important because as a FSharp dev, you don’t really want to look at the CSharp code.  All you really want  to do is extract the interface:


1 interface ICustomerCreator 2 { 3 Customer CreateCustomerForAnOrder(Order order, string firstName, string lastName); 4 }

With the interface in place, you can now create a FSharp project in the solution and begin your implementation of it:

1 namespace ChickenSoftware.CustomerManagementExt 2 3 open ChickenSoftware.CustomerManagement 4 5 type BetterCustomerCreator() = 6 interface ICustomerCreator with 7 member this.CreateCustomerForAnOrder(order, firstName, lastName) = 8 new Customer()

(Note I wouldn’t call it ‘BetterCustomerCreator’ for real, even if it is better). 

You then can enter your next meeting saying, something like “I created functional equivalence with the enhancements of fewer bug, better readability, and mutli-threading support.”  The PM will say, “that is awesome” and the developers who no longer code (typically called architects in large companies) will protest that it is in a different language.  But now you have the PM on your side and you can have a discussion about finding qualified people to work in F#.  My experience there is that the developers you want to work with will jump at the chance and the devs you don’t want on the project will balk at learning a new language/mindset.  You can also mention that the really good C# devs are already using linq an lambdas so they are already transitioning to FSharp.

The last point is that you need to back up the statement you made originally that FSharp reduces the number of bugs and delivers software faster.  If you are a .NET dev,  I would recommend listening to Bob Martin when he says that you need to spend 20 hours a week outside of your primary job (as he mentions here) and learning a functional language (as he mentions here) learning FSharp.  That effort, coupled with the FSharp community (the best community you will find) will certainly allow you to walk the walk.  There will be detractors at every turn who will point to any slowdown to a FSharp codebase as proof that CSharp would have been perfectly fine.  The only thing I can say there is “Don’t let the turkeys get you down.” and manage expectations that FSharp is not a silver bullet and that there are places where CSharp is more appropriate.  Be the voice of innovation and reason, don’t be the functional dogmatic in the room.  So far it was worked for me, and I hope it works for you.

4 Responses to Adopting F# in a C# Shop

  1. Yawar Amin says:

    Just out of curiosity–would you say just talking about & showing the comparisons people have already done would be a good strategy–e.g. Simon Taylor-Cousins’ comparisons of codebases originally written in C# and then re-implemented in F#, showing the sharp drop in lines of source code (order of magnitude less), simpler dependency structure, etc. etc.?

  2. Pingback: F# Weekly #46, 2014 | Sergey Tihon's Blog

  3. Pingback: Venturing out – rickpackblog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: