Sometimes when I talk to C# developers about F#, they say they don’t want to switch to a functional programming language. When I reply that F# is my favourite object-oriented programming language, they look a bit puzzled. They typically think that F# is for functional programming, while C# is for object-oriented programming. And this is wrong!
When comparing complex data types in unit test assertions, for example, records with nested lists containing discriminated unions, the error messages quickly get hard to understand. How to spot a single difference?
That’s why I mixed Unquote and D-Edge.Diffract together.
An example unit test from our codebase:
“F# code is full of operators, making the code unreadable.” said a C# developer to me once. And he is not the only person to dislike F# for its operators – not specific operators, but the sheer number of operators there are.
Before continuing reading, take a moment and guess the number of operators in vanilla C# and F#.
A few days ago, we embarked on the process of tidying up a particularly complex piece of code. It involved moving typical frontend code to the backend, as it was becoming too cumbersome and we felt more secure writing it in F# in the backend. (more on that in another blog post) After much of it was rewritten, we ran into a pattern matching construct that threatened to contain a lot of code duplication. To increase readability, we wanted to use an Active Pattern. The problem was that the...
F# makes it easy to model a domain with discriminated unions (= it is one of these values) and measures (type-safe numbers). Excerpt from our expenses sub-system:
When I show F# code to non-F#ers, I often get a reaction that goes something like this: “This code looks kind of nice, but we don’t have math problems to solve, so F# is not for us.”
By the way, the code I show typically has nothing to do with math. We don’t solve math problems with F#. We write a business application with it.
So I wonder why I hear this almost every time when I present about F#. Some guesses:
Today’s random F# code from our app is about using Results instead of using exceptions.
Do you often need to get some data from the database, but it’s not sure that the requested data exists? And you don’t like using exceptions for this because exceptions are for really unusual things? Then use a Result:
Querying data with the help of Result
Today’s random F# code from our app is about validating data passed to us over our public API:
Example code showing the usage of FsToolkit.ErrorHandling’s validation computation expression.
C# indeed gets more and more features known to F#, like pattern matching, switch expressions, records, a way to deal with nulls, and someday maybe even discriminate unions and deep equality on collections. Maybe even type inference could become as powerful as in F#. However, C# can’t eliminate the features it already has, like mutability by default and statements. Immutability by default and expressions-only are strengths of F# and make building error-free apps easier. Real pipes and...
Today’s random F# code is about type inference. If you like var, default and new() in C#, you might like F# a lot because F# gives you type inference also for function parameters, return types and generics (grey = IDE showing the inferred function signature):
F# type inference examples