After one of my presentations about F#, we had a discussion about the effect of type inference, resulting in almost no type annotations, on code readability and reviewability. The concern was that it makes the code harder to understand, especially when reviewing code, for example, outside of an IDE (GitHub/Azure DevOps/… Pull Requests).
So is there a problem or not? Let’s see.
In this blog post, I describe the way we currently work as a team to deliver our product (TimeRocket) to our users and customers. This reflects our current understanding of working in an agile* way that matches our needs and skills. We are uncovering better ways of developing software by doing it and helping others do it. Manifesto for Agile Software Development (agilemanifesto.org) As the manifesto for Agile Software Development states, we continuously try to improve our way of working, so...
Sometimes, unit tests are really small – so small that they fit on a single line:
In F#, you specify the order of files explicitly. Any code can only reference types, modules and functions that are higher up in the same file or in a file higher up in the file list. When starting with F#, this feels strange because most programming languages don’t rely on ordered files. Some call this feature even dumb.
A recurring claim is that OOP languages, in general, are faster than FP languages – or specific to .Net, C# is faster than F#. So today, we take a look at the myth about F# being slow.
We use NodaTime in our application to deal with time. As you may remember, time is very important in our application – it’s a attendance time-tracking tool with duty planning and many more features. For example, we use Instant to model a point in time. But sometimes, we need a point in time with a granularity of minutes, not nanoseconds. Instead of introducing our own type to model an instant with minute granularity, we use an Instant with a measure. Let’s see how this works:
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...
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.
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.