Menu

On the 5th of June* at work we decided to give F# a go and by ‘go’ I/we mean really use it in the most important parts of our application. Some of the team has had greater exposure to functional languages like Haskell and Scala, they are the ones being our champions and guiding the rest.

*I know the exact date because it is marked by a small commit of a blank F# project added to the solution I went back and checked.

This was not a snap or rushed decission but one with a fair few chats over code examples and a proof of concept.

If I have to boil down the decission to go ahead with F# at this early stage it is:

Record Types

Patern Matching

Immutability

These language features combined with team motivation to be working with something new and interesting “sold” the rest of us who haven’t didn’t have the exposure yet.

At this point I want to confess that it’s a strange feeling to be working with F# code and not having the same level of confidence to make changes and jump in and write like I would with my near decade of experience in C#. Many would argue that that’s actually quite a good thing, and I’m starting to agree – for one thing it means I’m thinking longer about the code.

It’s very easy to just write some procedural logic, call some methods, change variables, and just keep writing until it works and think about tidying it up after the fact, or worse leaving a “//TODO: clean this up” comment for a future self or peer to rage over.

Take the preceding paragraphs and the title of the blog post as my disclaimer that this is all new to me but here goes… My take on the concepts I understand and apprecaite about F# so far are simple and based on and how it’s helping me and the team so far to write code more easily.

Record Types

Concise / less code

In our CQRS style application we have lots of little commands (that’s what the C stands for), and lots of events so being able to very succinctly create these is a huge win.

Pattern Matching

Immutability

Concise

Of the 3 things I this is the most fundamental F# concept that I can appreciate so far, at a mimimum it’s about avoiding side effects in your code, and makes you think about transforming data as it flows through your application. In our CQRS world this is a great match, a command gets populated, it shouldn’t change. An event gets produced, that’s even more definate it happened – here’s what happend it doesn’t change.

Did you notice the trend for each of the 3 items I chose to cover, that’s right it’s about being concise. The immutabilty may not always be less code but you absoultely do get conciseness. If you take 1 thing away from this is that how could less code possibly be bad, less to write, less to mainting, win, win.

That’s it for now, we haven’t had to give up and re-write all this code in C#.