In this chapter, I touch on an important aspect of the functional-first programming approach that kicks in when the F# code is in the process of being developed. It so happens that the troubleshooting of the functional-first code differs from the troubleshooting of, say, imperative code. The goal of this chapter is to share with you some of my observations collected while authoring idiomatic F# code. It should leave you equipped with some considerations and a few techniques for effective bug squashing.
In this chapter, we will look into the following topics:
- Understanding reasons for idiomatic F# having a low defect rate
- Using REPL and explorative programming style
- Addressing some compile-time problems
- Addressing run-time problems
Without going back to the side-by-side comparison of functional-first and other paradigms available for F# programmer to employ, I will reiterate the (mostly anecdotal) point that an idiomatic F# code admits fewer defects than equivalent implementations based on object-oriented or imperative paradigms.
The previous twelve chapters have contributed significantly to this judgment. But let me briefly revisit some considerations in order to conclude that:
- This decrease in the defect rate is not something taken for granted. This artifact is what you gain in exchange for the pain of mind-bending while acquiring functional thinking habits and the following rigor in applying them
- The use of F# by itself is not a remedy from the defects; there is still enough space for bugs to sneak into the code, although in significantly lower amounts
- Typical F# bugs are quite specific and often may be anticipated and avoided
This observation is very important and stems from a few factors:
- The language's succinctness contributes to the reduced bug rate literally: fewer lines of code carry fewer chances for bugs to sneak in and stay unnoticed
- Strict static typing and type inference simply do not allow oversights that are typical for dynamic languages, when the misplacement of types may lead to bugs that are hard to detect and eliminate later on
- Raised level of abstraction, library higher-order functions, and immutability. All of these contribute to eliminating many bugs that come from the unpredictable execution order of stateful code, more "moving parts" involved, and needless re-implementation of core library facilities
The syntactic correctness of a program written using a conventional programming language usually does not prompt any assumptions about the outcome of its execution. Generally speaking, these two factors are not correlated.
It seems that this is not the case for the implementations following the F# functional-first approach. There is plenty of anecdotal evidence on the Internet in F# and non-F# functional programming context stating that
"if it compiles it works"
For example, this Haskell wiki post (https://wiki.haskell.org/Why_Haskell_just_works) states a similar observation in relation to programs written in the allied Haskell programming language.
Actually, strict static typing and type inference may catch many random defects at compile-time, shielding programmers from the costly process of observing a problem at run-time and then often performing lengthy and skill-demanding activities known as debugging in order to nail down the genuine cause of the problem at the source code level.
Another extremely important factor is to implement the algorithm by sticking to a handful of idiomatic patterns supported by core libraries instead of manipulating lower-level language constructs. To give you a better idea of what I'm talking about here, try to answer this question: Which approach carries more chances for implementation mistakes, folding a sequence with Seq.fold or materializing the sequence into the array and traversing elements using indexing while aggregating the result in a mutable value? The right answer easily translates into what has been mentioned on many occasions throughout the book: the positive effect of "minimizing the amount of moving parts" in a functional paradigm.
Still, your fold should be the rightly one for the overall correctness of the implementation from an algorithmic standpoint. And F# offers just another bug-squashing facility. This facility allows the developer to perform fast, easy, and frequent quick checks along the course of implementation with the help of so-called REPL covered in the next section.