Often we encounter algorithms with a certain structure that consist of individual steps that may vary for specific implementations.
To keep things clean and in order to reduce duplicate code we should refactor common parts out.
The object-oriented solution to this is the Template Method design pattern.
But there might be an alternative, better solution to this that uses higher-order functions.
Continue reading →
There are two great articles by Scott Wlaschin on how functional programming can be used for the domain design of real-world applications by implementing a Tic-Tac-Toe game. He demonstrates how business rules can be modeled with types, how data hiding, encapsulation, logging and capability-based security can be achieved with functional programming and more.
What I found remarkable is that in the second article he completely re-engineered the first design. Even though to me the original implementation appeared to be very appealing.
I liked that the data-centric domain model was concise, totally clear and very close to the natural notion of the game. Eventually it couldn't meet high security standards since there were ways for malicious users of the API to manipulate the data.
The second function-centric implementation introduced the concept of capability-based security. The design smells of the previous version could be resolved. But I argue that the API of the second version is not as intuitive as the first one anymore. Technically it is also quite simple. However, the recursive structure doesn't come totally natural to me. Also an indicator that the second version is more complex is that logging becomes trickier.
Continue reading →
I have been playing around with FParsec a little bit lately, inspired by the chapter 8 "Functional Parsers" of the book Programming in Haskell by Graham Hutton. FParsec is an F# parser combinator library for building quite powerful parsers by combining primitive parsers and functions provided by the FParsec library.
If you haven't been exposed to the concept of functional monadic parsers then this can be a very different experience. I am still totally fascinated by the power and the simplicity of this concept. Here is a brief introduction in C#.
As an exercise and to learn the usage of FParsec I have been looking for code that could be refactored to FParsec.
This is a follow-up from my last post Functional Monadic Parsers ported to C# where I showed the implementation of basic parsers from the book Programming in Haskell by Graham Hutton in C#.
When these primitives are used to compose a parser for Roman Numerals the result yet again demonstrates the amazing capabilities and elegance of functional programming. The problem of parsing Roman Numerals is not a very difficult one. But still, I find the simplicity of constructing a solution by combining primitive parsers fascinating.
Here is the implementation. It is super easy, I was able to write this in less than 15 minutes without tests first, worked the first time.
Continue reading →
While taking the MOOC Introduction to Functional Programming by Erik Meijer on edX the current lecture greatly increased my interest in functional parsers. Functional parsers are about the essence of (functional) programming because they are about the concept of composition which is one of the core concepts of programming whatsoever.
The content of the lecture is closely related to the chapter 8 Functional Parsers of the book Programming in Haskell by Graham Hutton. It starts out with the definition of a type for a parser and a few very basic parsers.
I'm totally amazed by the simplicity, the elegance and the compositional aspect of these examples. I find it impressive how primitive but yet powerful these simple parsers are because they can easily be combined to form more complex and very capable parsers.
As an exercise, out of curiosity, and because of old habits I implemented the examples from the book in C#.
At the end of this post there will be an ultimate uber-cool parser example of a parser for arithmetic expressions.
The complete code from this post can be found here on GitHub.
Here is what I got:
In the previous posts of this series we have seen how functional error handling can be implemented in F# and C#.
Now let's look at an implementation of the command line parser using the Notification Pattern.
This is the third part of the series Functional error handling in F# and C#. In this post we will see how the command line argument parser with functional error handling, that was shown here using F#, can be implemented in C#.
In this post, which is the second part of the series Functional error handling in F# and C#, we will examine an application for parsing command line arguments with error handling.
The functional approach uses Applicative Functors. Applicative Functors and the basics of functional error handling, only with immutable objects and without the use of exceptions, are explained int the first post of this series: Error handling with Applicative Functors in F# and C#.
A complete solution with all the code samples from this series can be found here.
As a starting point I took this F# console application template and reimplemented it with railway oriented error handling in F# and C#. The original version writes error messages directly to the console, which is totally ok in many situations. However, the railway oriented approach offers a bit more flexibility and safety because it will let the caller decide on how to handle the failure cases.
In an object-oriented context a typical way to do error handling is to use the Notification Pattern described by Martin Fowler.
In functional programming (FP) the approach to error handling is very different. Error handling has to be done without mutating state and without the use of exceptions. The concept that is capable of this, and that is commonly used in FP is called "Applicative Functor".
In this post, which is the first part of the series Functional error handling in F# and C#, we will cover all the basics that are needed to do functional error handling in F# and C#, and to understand Applicative Functors.
The F# and C# code samples from this post can be found here.
In the second part of the series we will look at a sample application for parsing command line arguments with error handling in F#.
Anyway, before we jump right into it, we will need some introduction.
Some time ago when I started learning functional programming I also started to follow functional programmers on twitter. Some day someone stated that error handling should be done with Applicative Functors.
No, Martin Fauler, you should use applicative functors instead http://t.co/kLCJvLazqE
— vaskir (@kot_2010) December 9, 2014
Off course the Fowler way is a very typical, commonly used and approved approach. So what makes it so much better to use Applicative Functors instead? And what are they anyway?
This series of posts will answer these questions. It is the kind of article I was looking for back then but could not find. It is a compilation of all the pieces and resources that I found researching the topic.
In the first part we will cover all the basics that are needed to do error handling in a functional style, and to understand what is going on behind the scenes. We will see how error handling can be done only with immutable objects and without using exceptions.
In the second part of the series we will look at a sample application for parsing command line arguments with error handling in F#.
Content of this series:
Error handling with Applicative Functors in F# and C#
Basics of functional error handling
Functional error handling - parsing command line arguments in F#
Functional error handling in practice (F#)
Functional error handling – parsing command line arguments in C#
Functional error handling in practice (C#)
Functional vs. imperative error handling
A comparison of the functional vs. the imperative approach to error handling