Error and state handling with monad transformers in Scala

In this post I will look at a practical example where the combined application (through monad transformers) of the state monad and the either monad can be very useful.

I won’t go into much theory, but instead demonstrate the problem and then slowly build it up to resolve it.

You don’t have to be completely familiar with all the concepts as the examples will be easy to follow. Here is a very brief overview:

Continue reading →

Use lambdas and combinators to improve your API

If your API overflows with Boolean parameters, this is usually a bad smell.

Consider the following function call for example:

toContactInfoList(csv, true, true)

When looking at this snippet of code it is not very clear what kind of effect the two Boolean parameters will have exactly. In fact, we would probably be without a clue.

We have to inspect the documentation or at least the parameter names of the function declaration to get a better idea. But still, this doesn’t solve all of our problems.

The more Boolean parameters there are, the easier it will be for the caller to mix them up. We have to be very careful.

Moreover, functions with Boolean parameters must have conditional logic like if or case statements inside. With a growing number of conditional statements, the number of possible execution paths will grow exponentially. It will become more difficult to reason about the implementation code.

Can we do better?

Sure we can. Lambdas and combinators come to the rescue and I’m going to show this with a simple example, a refactoring of the function from above.

This post is based on a great article by John A De Goes, Destroy All Ifs — A Perspective from Functional Programming.

I’m going to take John’s ideas that he backed up with PureScript examples and present how the same thing can be elegantly achieved in Scala.

Continue reading →

A Markdown Based Adventure Engine – My First Playing Around With Elm

My recent little adventures in Elm have definitely been one of the most enjoyable programming experiences.

Elm is a purely functional programming language that compiles to JavaScript. It has static type checking, all values are immutable, there are no null references, and no runtime exceptions. Additionally Elm has a great performance due to the implementation of a virtual DOM. All apps written in Elm are structured by the same simple pattern called The Elm Architecure.
Continue reading →

Purity in an impure language with the free monad – by example of a Tic-Tac-Toe backend with CQRS and event sourcing

This post is part of the F# Advent Calendar in English 2016. Please also checkout the other posts or the F# Advent Calendar 2016 eBook.

Pure code intermingled with impure code.

This is not a very good separation of concerns and has many other disadvantages.

Here is an example of how many programs look like:

alt

In Haskell e.g. this would not be possible. But how should we deal with this in an impure programming language that does not enforce side effects to be made explicit, like F# e.g.?

There are a few approaches that will be presented in this post, one of which is the free monad pattern.

We will also examine a proof of concept implementation of a Tic-Tac-Toe backend following the command query responsibility segregation pattern (CQRS) together with event sourcing (ES).

See how you can implement a program in F# that is entirely pure and free from any effects and side effects!
Continue reading →

SameGame with F# and Fable: Functional programming meets JavaScript

Fable is a compiler for F# to JavaScript.

It brings all the good parts of functional-first programming in F# to JavaScript development.

Even without a lot of knowledge of Node.js and the JavaScript ecosystem, it is fairly easy to get started with and use functional-first programming for client-side browser applications. Fable can also be used for client-server, Node, mobile or desktop applications.

After reading the very nice introductory tutorial Getting started with Fable and Webpack I was ready to make an implementation of SameGame.

It is integrated in this post and you can play it right here in the browser.

This sample was also published on Fable’s official sample site where you can find more information on the implementation details.

Continue reading →

Functional error handling in F# by example

Exceptions are bad.

Not only do we have to remember to catch them everywhere, they also provide a second implicit exit strategy for functions, similar to the goto statement.

However, there is an alternative more explicit approach.

In this post we will go through an example of how to implement decent functional error handling in F# without using NULL or exceptions.

We will do this by extending the application from the last post and make it even more reliable and robust.

Continue reading →

Template Method Pattern. Can we do better?

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 →

Domain Design, data- or function-centric?

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 →

Refactoring to FParsec

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.

Continue reading →

Parsing Roman Numerals in C# and Haskell

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 →