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...
Myths about F#: Imperative code is simpler than functional code! No, not at all, but you are more used to it.
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.
Myths about F#: F# is for FP, C# for OOP! No, F# loves OO.
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!
Myths about F#: F# has too many operators! Many, but not more than C#.
“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#.
Myths about F#: F# is for math problems only! No, F# is a general-purpose programming language.
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:
Myths about F#: C# will become F# anyway, so we don’t need F#! Nope, not happening.
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...
Test Driven Development Myths
I’m often hearing thoughts about Test Driven Development from people not using it, which are not true (at least not 100%).
Therefore, I want to describe some of these myths here:
Writing unit tests is difficult and complex
Projects take longer because of the additional test code that has to be written
Not everything can be tested with unit tests. Therefore TDD cannot be used.
There is no need for architecture and design because TDD claims to evolve that from tests