I was invited by JetBrains to talk about OOP and FP and how C# and F# support these paradigms.
Here, you can find the Recording.
And here are the slides.
Happy combining of OOP and FP in your code!
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.
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:
Simple:
Difficult:
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 we started with TimeRocket in 2015, we used C# as the programming language for our backend. In 2020, we started using F# for our new code. We see little value in rewriting existing C# code to F# and do so only when major changes are due in existing C# code. As a result, we have quite a bit of C#-F# interop in our system. Both from C# to F# and from F# to C#. This post overviews what we learned about C#-F# interop. This blog post is part of the F# Advent Calendar 2022 – check out the...
In June 2019, Microsoft introduced System.Text.Json as a feature of .NET (core) 3.0 to the public. The reason they gave for creating this new namespace was that they were unhappy with the old built-in solution for serializing / deserializing JSON. The poor built-in capabilities to work with JSONs –of course- was the reason for James Newton-King to create Json.Net (for many of us just called Newtonsoft, which actually is his company and not the name of the library). Newtonsoft’s Json.Net...
On our journey from C# to F#, we were at a point where we changed our (unit) testing strategy. Our approach just didn’t feel right anymore. We struggled to do TDD because we didn’t get the tests to fail first. We wrote tests that didn’t increase our confidence and started thinking of them as waste.
This post is part of the F# Advent Calendar 2021
Thanks to Sergey Tihon for organising the Advent Calendar.
There are many libraries for JSON serialization in the .Net realm. The best known are probably Newtonsoft’s Json.NET and System.Text.Json. Both can’t handle F# discriminated unions very well. There are also a couple of F# JSON libraries available like Thoth.Json or FSharp.Json. They are all great libraries, and choosing one is about making trade-offs. However, our case is a bit complicated because we have a mix of C# and F# code. This results in object/value graphs that consist of a...
This is part 5 of how we generate types from our .Net backend to be used in our TypeScript client. Why do we even bother?Generating TypeScript constants from .Net constantsFinding the types used in communication between the .Net backend and the TypeScript clientGenerating TypeScript classes from .Net typesGenerating Angular Services from .Net WebApi ControllersTypeScript-friendly JSON serialization of F# typesTesting JSON serialization and deserializationPutting all the parts together...