When we refactor code how can we be confident that we don't break anything?
3 of the most important things that allow us to refactor fearlessly are:
In this article we will solely focus on the aspect of side effects and strictly speaking on how to identify them. Being able to identify side effects in our programs clearly is the precondition for eliminating them.
Have you ever wanted to try out PureScript but were lacking a good way to get started?
If you
This post is for you!
In this post we will walk through setting up and implementing a small exemplary PureScript application from scratch.
In this article I would like to present a minimal implementation of a music data type and everything that is needed to turn that into audible sound from an Elm application.
We will see how to transcribe an existing composition - an excerpt from Chick Corea's Children's Songs No. 6 - and listen to the result right here,embedded in this article.
My colleague Jonas recently pointed out the presentation Making Algorithmic Music by Donya Quick to me. Donya Quick shows how she uses the Haskell library Euterpea to produce algorithmic music.
It got me really excited about the idea of porting this to Elm and to be able to use this in web applications.
In the following we will see the core data types and algorithms from Euterpea ported to Elm. To focus on the core concepts the implementation is stripped down to the minimum that is required to transcribe and perform an existing polyphonic piece of music (for a single instrument).
This post is about how to implement well structured,and purely functional command line applications in Scala using PureApp.
PureApp originated in an experiment while refactoring out some glue code of an interactive command line application. At the same time it was inspired by the Elm Architecture Pattern,and scalaz's SafeApp,as well as scalm.
To show the really cool things we can do with PureApp,we will implement a self-contained example application from scratch.
This application translates texts from and into different languages. And it provides basic user interactions via the command line.
The complete source code is compiled with tut. Every output (displayed as code comments) is generated by tut.
Continue reading →
In this post we will see how applicatives can be used for validation in Scala. It is an elegant approach. Especially when compared to an object-oriented way.
Usually when we have operations that can fail,we have them return types like Option or Try. We sequence operations and once there is an error the computation is short circuited and the result is a None or a Failure.
Applicatives allow us to compose independent operations and evaluate each one. Even if an intermediate evaluation fails. This allows us to collect error messages instead of returning only the first error that occurred.
A classic example where this is useful is the validation of user input. We would like to return a list of all invalid inputs rather than aborting the evaluation after the first error.
Scala Cats provides a type that does exactly that. So let's dive into some code and see how it works.
After some initial struggles,the chapter Functional Parsers from the great book Programming in Haskell by Graham Hutton,where a basic parser library is built from scratch,significantly helped me to finally understand the core ideas of parser combinators and how to apply them to other programming languages other than Haskell as well.
While I recently revisited the material and started to port the examples to Scala I wasn't able to define a proper monad instance for the type Parser[A].
The type Parser[A] alias was defined like this:
To test the monad laws with discipline I had to provide an instance of Eq[Parser[A]]. Because Parser[A] is a function,equality could only be approximated by showing degrees of function equivalence,which is not a trivial task.
Also the implementation of tailRecM was challenging. (I couldn't figure it out.)
Most config libraries use a stringly typed approach.
Some handle runtime failures due to invalid configuration schemas by leveraging data types like Option or Result to represent missing values or errors. This allows us to handle these failures by either providing default values or by providing decent error messages.
This is a good strategy that we should definitely stick to.
However,the problem with default values is that we might not even notice if the configuration is broken. This could potentially fail in production. In any case an error e.g. due to a misspelled config property will be observable at runtime at the earliest.
Wouldn't it be a great user experience (for us developers) if the compiler told us if the configuration schema is invalid? Even better,imagine we could access the configuration data in a strongly typed way like any other data structure,and with autocompletion.
Moreover,what if we didn't have to write any glue code,not even when the configuration schema changes?
This can be done with the costs of an initial setup that won't take more than probably around 5 minutes.
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:
If your API overflows with Boolean parameters,this is usually a bad smell.
Consider the following function call for example:
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.
I'm currently working on an sbt plugin that generates Scala case classes at compile time to model JSON API responses for easy deserialization especially with the Scala play-json library.
The plugin makes it possible to access JSON documents in a statically typed way including auto-completion. It takes a sample JSON document as input (either from a file or a URL) and generates Scala types that can be used to read data with the same structure.
Let's look at a basic example,an app that prints the current Bitcoin price to the console.
I don't get it. Even in a statically typed language like C# you can change the domain model and your application will still compile as if nothing happened. In this post we will address this and see how F# can help with such pitfalls of C# enumerations.
The problem with enumerations is simply that when we add new cases especially in a large code base, it can be really hard to find and update all dependent source code which might lead to errors at runtime.
The compiler will not help to find all the places that have to be updated. A text-based search isn't reliable.
Here is how things can go wrong.
Let's say we have an enum Directions:
Now we add a case for Up.
In switch statements the default case might be selected accidentally:
If there is no default case, an exception will be thrown:
This code will compile:
And it certainly should not because this leads to the other problems described before.
As we can assign arbitrary integer values to an enum also unit testing cannot be a sufficient strategy to find unhandled cases.
MSDN addresses these problems and for more robust programming they suggest the following:
If other developers use your code, you should provide guidelines about how their code should react if new elements are added to any enum types. --enum (C# Reference)
However, coding conventions are not checked at compile time.
I think we can do better.
I recently had that. I added a new enumeration case and searched and updated all usages. All tests passed. Anyway, I wasn't 100% confident that I hadn't missed a thing.
Wouldn't it be nice if the compiler just pointed out all the places we have to update after we change the model?
...and improve the reliability and robustness of our C# code.
It is possible to have the compiler check that all places are updated. And then we can have really high confidence that everything will work as expected. We will simply know.
We can achieve this with the help of F#'s discriminated unions.
Even though discriminated unions can do a lot more they can be used in a way that is very similar to enumerations.
Let's look at what we have to do.
First we add an F# class library project to the solution and reference it from the other projects.
Then we define the type Directions as a discriminated union with the two empty cases Left and Right:
After we have built the F# project we can use it from the C# code.
Instances of Directions can be created with static properties like this:
Discriminated unions provide properties to check for their case.
For discriminated unions with empty cases checking for the case and evaluating equality is actually the same:
In F# there are no switch statements. Instead match expressions are used for pattern matching.
The ToDisplayName function can be implemented like this in F#:
If we add the value Up now, we will get a compiler warning.
The compiler will warn us if a pattern match is not exhaustive. This way we cannot miss to update code that otherwise might fail at runtime.
So this is nice. But how can we take advantage of this exhaustive case check in our C# project?
We will simply define an extension method Match that we can call from our C# code, as described in this article by Mauricio Scheffer.
For each case we have to pass a generic function that creates the corresponding result.
Here is the implementation:
Now we can replace the switch statement by calling the Match function like this:
Like this there is no way that we can miss to handle a case.
There are no disadvantages compared to switch statement. Sure, switch statements can be non-exhaustive. But I hope that it has become clear by now that this is not good.
If you rely on any of the built-in behavior or members of the C# enumeration type, they can easily be simulated.
Explicit conversion to the underlying numeric type can be handy when storing enum values in a database or when comparing enum values to each other.
We can implement static and instance members for discriminated unions that simulate this behavior like this:
Likewise we can implement other behavior according to our needs.
Note that the "deserialization" function Parse returns an optional value. An alternative would be to define a case for Directions.None.
Or e.g. instead of Enum.GetNames we can use FSharpType.GetUnionCases:
When the scope of an enumeration type is really small and when it is not likely that it will increase in the future, it might be unnecessary overhead to use a discriminated union instead.
Also when we use an enumeration type to define bit flags we should stick with it.
In any other case, I would say, it makes sense because it makes programming more reliable and robust.
One last thought. If we use enums or discriminated unions with only empty cases, this might be a sign that our domain model is not ideal.
Here is an example of a poorly designed model to represent a shape:
With this model it is easy to represent invalid state e.g. like this:
With discriminated unions it is possible to design the model in a way so that invalid state is unrepresentable:
We can instantiate shapes in C# like this:
So extensive use of enums or empty discriminated unions might be a code smell. Consider to model your domain with algebraic data types instead.
Switch statements are not exhaustively checked. Therefore we have no guaranty that all cases of an enumeration type are handled even if our program compiles.
Furthermore enums can carry invalid values.
To make programming more reliable and robust we can replace enums with F#'s discriminated unions and use them from C# projects quite easily.
To do this we have to define a discriminated union with empty cases and a Match extensions method.
Then we can replace switch statements by calling the Match function.
If we add more cases to the type, the compiler will produce warnings or errors. This way it will be easy to find and update all usages and we can have very high confidence that our program won't fail at runtime.
Finally, extensive use of enums or empty discriminated unions might be a code smell. Consider to model your domain with algebraic data types instead.
Please check out these posts that are related to designing with algebraic data types: