My Journey into F#

Ody Mbegbu
Real World F#
Published in
5 min readJun 26, 2016

--

I first heard of functional programming from a friend of mine (Ifelere) this was I think 2011 back in my days at Dragnet. He mentioned that he was learning Erlang and it was this weird functional language. I think this was actually the first time I heard the word “functional language” and mixed it up with “procedural language”

Fast forward to a year later and I was now in Cyberspace and during this period, I had like a two hour commute. Like I typically do, I used this opportunity to catch up with podcasts. I was listening to an episode of .NET Rocks titled “Yan Cui Builds Games in F#” where the guest Yan Cui talked about how he used F# to build online games with complex logic. He made statements like

“What would typically take a Java Programmer 2–3 days takes me 3–4 hrs”

among others. He pretty much sold the language to me and so began my F# journey

Right off the bat when I saw the syntax, it looked clean but it felt crazy to me. It didn’t have the typical “structure” I was expecting. The following things rubbed me the wrong way about F# and one by one I would meet said weirdness, swear off the language, would later watch a talk or see a piece of documentation either proffering a solution or explain the reason for it. and one by one I was able to get over the weirdness

Cons

  • Significant white space — This felt crazy to me, having source code errors that I literally could not see.. However, I later found out that F# has a more verbose syntax (VB? lol) if you want and you can switch it off. After all, you do use Visual Studio to format your C# code and so it’s not that far off. In practice however, I got used to it. But its nice to know its there if you want to sweep complex logic on a single line.
  • Sequential Compilation — In F# like C++, the order in which files are compiled matters. I did not like this and it felt like a step backwards, but later I figured that its the same with JavaScript/TypeScript where your files represented modules not single classes. This means that an F# file would be roughly equivalent to a C# folder so I’ve come to terms with it. Also, more importantly It means that you can read code from large F# projects the way you read novels.. From the beginning.
  • Cyclic Dependencies — In F# circular dependencies need to be defined at the same time. Which is nuts if you are coming from C# where your class could “see” all classes in the project. I later discovered that they are actually evil

However, given enough time and several talks from Don Syme, Tomas Petricek, Rachel Reese etc and I decided to give it a shot and took two Pluralsight courses on it.. the better one (F# Fundamentals) was the course that completely pushed me over the edge. In fact, it was the red pill.

In the course you build a nokia composer. Here are some of the things that shocked me about F#

Pros

  • Simple Code — I used to hear people that F# produces “simple” or “clean” code but I didn’t really appreciate it. All the above cons are significantly reduced from the mere fact that “There is just so little code”. At this point, I wouldn’t be surprised if the core logic of Jet.com is a few DLLs. Its that dramatic. In the course, he wrote a complete nokia composer parser in roughly 100+ lines! the Domain was modeled in 8 lines! Whereas in idiomatic C# that would be at least 8 files. I mean, In how many ways can you screw up 8 lines? Even if you could, Its just 8 lines, fixing it would be easy
The Entire Domain Code for the Nokia Composer Application. Technically this snippet contains ~30 classes under the hood.
  • C# Superset — F# has everything that C# has. It can do pure OOP. In fact, at times the F# equivalent is cleaner and clearer than C# with respect to Interfaces, using statements, out parameters and more.
  • Ultimate Type Safety — I’m a big fan of type-safety in programming languages and even though F# looks dynamic like python, It’s more statically typed that C#! and that’s saying something. With things like Type Providers, even your Application Settings in your App.Config file can be checked by the compiler at build time
  • Superb Type Inference — To make Ultimate Type Safety feasible without looking cryptic as hell, F#’s Type inference is nothing short of exceptional. Combined with the forward compilation, it can narrow down types when they are used. You can think of it as “Generic Generics” because where C# generics allows you to not specify the types up front, F# allows you to not specify the generic parameters up front.. pretty meta

Verdict

Its safe to say that I’ve fallen in love with the language. Moving forward, I intend to start writing all my .NET apps in F#.

Don’t get me wrong, C# is still a superb language and I don’t intend to drop it completely.. (It is still what I use at my day job) but I’m at the moment of my journey as a developer where I’m so familiar with C# that I can manipulate and bend it to my will.. for example tweaking the Linq Syntax for the Operation Library

C# Expert

But more importantly, I can clearly see its limitations.. For example, why is void not a type?. F# for me feels like the next level.
That said, the relationship is not a bed of roses. There are a few things that still irk me about F# development. Some of which

  • Sub-Par tooling — F# tooling in VS is still horrendous compared to C#. In developing ASP.NET web applications, I still have to crack open fsproj every now and then or add Assembly Binding Redirects manually which is still painful.
    Yes, F# PowerTools helps but it sticks out like a sore thumb sometimes with its own menus and dialogs. Dotnet Core looked promising to level the playing field but still F# is still behind in that area as well.
  • Poor Documentation — The MSDN docs for F# are sub-par at best. It feels very much like a manual. Thankfully, there is a website fsharpforfunandprofit.com that has better documentation. But there aren’t that many docs that cover specific technologies like F# with EntityFramework or ASP.NET, Owin, Katana etc.

It took me a while to fully wrap my head around F# but I think it was worth sticking with. It came just as I was starting to get bored with C#. Most of the patches and solutions I built for C# were already part of the language e.g. Piping, Simplified using statements, Computation Expressions e.t.c.
For the first time in a long time, I get excited to wake up at 3 am and start coding and that means a lot to me.

--

--