A typical conversion: Me: “Did you take a look at F#?”Paul*: “No, it’s just too hard to learn!”Me: “Why?”Paul: “I don’t understand anything because of the syntax.” *Paul = Person assuming unyielding learning F# isn’t hard to learn. But you probably have to learn four concepts that you may never have seen before** **unless you have experience in other functional programming languages Let’s see these concepts and how you can...
Most code running on .Net is written in C#. So when you consider writing some code in F#, you probably already have a good amount of C# code. C# code you want to keep. It probably doesn’t make economic sense to port C# code to F#.
The good news is that you can start using F# anyway. F# and C# have excellent interoperability.
We use event sourcing in many sub-systems of our application to store data. We serialize the data of the events as JSON and store the JSON in the database. To ensure that we don’t change the structure of these event data and by this introduce backward compatibility issues, we use Verify to snapshot test the event data.
Just today, I read on a social media platform that the author doesn’t like that most programming languages incorporate more and more functional features. The post was accompanied by a short example of pattern matching in C# using some of the features introduced in the latest updates. More generally, I hear and read repeatedly from people that tried to write code in a more functional programming style in C# but weren’t happy with the resulting code. The code was just too hard to read...
A myth about F# that I hear repeatedly is that imperative code (e.g. loops) is simpler than functional code (e.g. folds). On one hand, simplicity is very subjective. On the other hand, simplicity is mostly determined by familiarity.
A typically used example is something like the following:
Let’s see what’s wrong with this myth.
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: