DEV Community: Jakob Christensen

You owe it to your team to let them try F#

Jakob Christensen — Mon, 11 Apr 2022 21:55:00 +0000

If you are the lead or senior of a team of developers that build applications in C#, this is for you.

Let me just throw it out there for you:

TL;DR

You owe it to your team to let them try F#.

Give them time to write a new project or just a new component in F#. They will thank you later. And so will your management.

This turned out to be a lengthy post, so here is a table of contents.

C# feels good, but...
Fewer bugs
- Make invalid state unrepresentable (and no more null-reference errors)
- Easier testing
Faster time to market
- Immutability
- Less code
- Better domain modelling
Faster onboarding of new employees

C# feels good, but...

If you are like me, you have been building applications in C# for years. C# makes you comfortable. C# makes you happy. And your team can build just about anything in C#.

But maybe, just maybe, you have a nagging feeling that some things didn't have to be so hard to understand, or requests for changes did not have to feel so overwhelming.

Maybe that feeling comes after the umpteenth time your team has chased down a null reference error reported by a user.

Maybe that feeling comes when the your team has spent way too much time adding a new feature, because it has some unexpected effect on the application.

Or maybe that feeling comes when there is a bottle neck on your team because the steep learning curve for your code base makes it really hard to bring in new hires.

As you have probably guessed by now, there is an easier way, and that way is F#. F# will give you:

Fewer bugs
Faster time to market
Faster onboarding of team members

I now this because we did it on our team. Below I will walk you through these bullets.

Fewer bugs

Applications without errors make happy users and if the users are happy, management and employees are happy.

After working with F# for about a month, one of my co-workers, who is very experienced in C#, said:

If F# compiles, it just works.

Of course, this is an exaggeration but there is a lot of truth in his statement. F# helps you build robust software with no surprising runtime errors. F# does that in a number of different ways, and I will walk you through two of those here:

F# gives you a way to make invalid state impossible, and
F# makes it easier for you to test your code.

Make invalid state unrepresentable (and no more null-reference errors)

Someone, and I'm not sure who, once coined the expression

Make invalid state unrepresentable.

It means that you should model your code in a way so that parameters and values can never take on a state that is not allowed in your program. One of the most dreaded errors in C# applications is the "object not set to a reference" error, which happens when you reference a null-object. That is, an object is null which is an invalid value for that case. For example, you might have some code that retrieves an object from storage:

// C#
var user = GetUserByEmail("alice@acme.com");
Console.WriteLine(user.Name);

What you cannot tell from this short example is, what happens if there is no user for that email address? Does GetUserByEmail return null? If it does, your code fails. You could add a check for null but the signature for GetUserByEmail does not give you any information on what to do.

In F# it is to model that in a way so that it is clear what happens if the user does not exist. In particular you could use the Option type and the F# code would look like so:

// F#
match getUserByEmail "bob@acme.com" with
| Some user -> Console.WriteLine(user.Name)
| None -> Console.WriteLine("User not found.")

Option can be either None or Some and the F# compiler will force you to handle both cases. This makes it very clear what getUserByEmail returns when there is no user and you won't accidentally reference a null-object.

You can model your own types in the same way as Option. While we are at it we might as well expand getUserByEmail so that we can identify users by other things than email, for example nick name. For that we can create or own type:

type UserIdentifier =
    | Email of string
    | Nick of string

let getUser identifier =
    match identifier with
    | Email email -> getUserByEmail email
    | Nick nick -> getUserByNick nick

As with Option, the F# compiler will force you to match all cases of UserIdentifier and hence you won't forget any cases and also, the caller of getUser won't be able to pass in any invalid values.

You can do even better. Above, email is represented by a string. But maybe you want to make sure that you only pass a validated email. You could create a new type ValidatedEmail that is guaranteed to only contain validated emails. The UserIdentifier type would then look like so:

type UserIdentifier =
    | Email of ValidatedEmail
    | Nick of string

I will leave the implementation of ValidatedEmail as an exercise for the reader 😏

Easier testing

We have been taught for years to write code that adheres to principles like the Open Closed principle and the principle of Inversion of Control. Personally, dependency injection has been my weapon of choice for so long, that I have lost sight of the why. And testing with mocks and stubs does not exactly lend itself to readable tests.

Functional programming has a different approach, since it is just... functions. Functions are all about inputting data and getting some other data back, which you will input into another function and so on.

You may visualize it like so with arrows:

let result = inputData -> function1 -> function2 -> function3

You can think of it as data flowing through a pipeline of functions. F# actually has a built-in "pipe" operator |> that does exactly that. It takes the output of one function and "pipes" it into the next:

let result 
    = inputData 
    |> function1
    |> function2
    |> function3

Yes, the above it valid F# 😃

You can even create new functions by composing other functions. That lets you define workflows in your system as a pipeline composed of a series of functions. That may look like so:

let doSomeBusinessLogic =
    validate
    >>= calculateFoo
    >>= calculateBar

let pipeline =
    readInput
    >>= doSomeBusinessLogic
    >>= saveOutput

Here, the >>= is just some special operator that I have defined. It composes two functions, hence doSomeBusinessLogic and pipeline are two functions composed from other functions.

You may want to read on one way to do that in one of my other entries here:

Impeachment in a functional way

Jakob Christensen ・ Jan 13 '20 ・ 4 min read

#functional #fsharp

The beauty here is that it is so easy to test.

You can choose to write tests for validate, calculateFoo, and calculateBar separately, or you can choose to test the entire doSomeBusinessLogic function as a whole. You can even go all in and just test pipeline. It is all up to you.

Also, note that this model isolates your business logic from communication with external resources like web services or databases. The boundaries towards externals are at the top and at the bottom of your pipeline.

Faster time to market

My second point is that F# will help your team get products faster out the door. Besides the better testing part that I went through above, I'd like to mention 3 ways that F# helps in this:

Immutability
Less code
Better domain modelling

Let us go through these bullets:

Immutability

Values in F# are immutable by default, that is you cannot change a value once it has been initialised. For seasoned C# developers like you and I that may sound horrifying. How can you get stuff done if you cannot change anything? But if you think about it for at bit, immutability takes a massive burden off your shoulders because you know that you won't risk a massive rippling side effect in your application if you change a variable.

That makes your code much more trustworthy and you can fearlessly add new features and fix bugs.

Which gives you faster time to market...

Less code

In F#, every line has a purpose. It is very concise and succinct. Constructs like the pipe operator |> and type inference saves you a lot of typing.

Which gives you faster time to market...

Less code also makes your code easier to understand which I will get back to.

Better domain modelling

As C# developers, we have always been told to use class hierarchies to model our domain. But if you think about it, domains really don't behave as mutable objects with some internal state and public functions that operate on that state, are they? The usual OO example model of Animal and Monkey really show that this kind of modelling does not work 🐵

No, if you want to model a domain with software, it is usually about modelling information (data) passing through a workflow (functions).

Which is exactly what F# is very good at.

Which gives you faster time to market...

Faster onboarding of new employees

You finally made it to my third and last argument for switching to F#.

I believe that F# is easier to learn than C#. This is a bold statement, I know. The thing is, C# is actually really hard to learn. You need to learn about classes, public/protected/private/static, inheritance, constructors, interfaces, and more. When that is done, you need to learn OOD, which is a never ending story.

Of course, you can do all of this in F# as well, because it is built on .NET after all. But you don't have to. You can build every application in the world just by knowing data and functions.

I also claim that an F# codebase is easier to get to know for new hires. The reason is that it has fewer abstractions. You don't have to hunt down interface implementations that have been dependency injected via a .config file in a completely different assembly.

Granted, F# does has functional constructs, that are hard to understand, for example the >>= operator, I showed you above. But you don't have to use stuff like that. Actually, the F# community encourages you to use it sparingly and stick with functions, data and the |> thing.

F# is all about keeping it simple. That is good news for juniors and new hires.

Filtering lists in F# without throwing data away

Jakob Christensen — Fri, 21 Jan 2022 16:46:43 +0000

A while back I got a new assignment that was a bit different from what we usually see. We wanted to send letters to a select group of clients but we were not able to say who should get the letter. We were only able to specify who should not get the letter.

So we started with a list of all clients and then we would remove people from that list in steps following a number of filter criteria.

Usually for these kind of assignments you would just apply a number of suiting List.filter and that's it. But not this time.

What made this task a little quirky was that we were required to log for each step who we removed from the list. So we needed something different from List.filter. Instead we needed a way to filter the list while for each step logging the persons we filtered away. It is like List.partition on steroids.

In pseudo-code the process looked like so:

readListOfPersons()
|> filterOnCriterion1()
|> writeExludedPersonsToFile()
|> filterOnCriterion2()
|> writeExludedPersonsToFile()
|> filterOnCriterion3()
|> writeExludedPersonsToFile()
|> writeIncludedPersonsToFile()

I wrote a small module Split that does exactly that. I recently cleaned it up and made it public on Github

t4rzsan / fsharp-split

F# Split

Split is an F# module for filtering lists but without losing the data that you filter away. If you use F#'s built in List.filter function, you have no way of keeping track of the items in the list that you filter away. With Split you can keep track of both the items that are included in the filter and the items that are excluded.

Take a look at Demo.fsx for an example on how to use Split. Also, check out this write-up on dev.to: https://dev.to/t4rzsan/filtering-lists-in-f-without-throwing-data-away-a7o.

View on GitHub

It is based on a simple type that holds a list for included items and a list of excluded items.

type Split<'a> =
    { Included: 'a list
      Excluded: 'a list }

You use the Split.create function for splitting a list into included and excluded using a predicate function.

[ 1; 2; 3; 10; 354; 234; 23; 45 ]
|> Split.create (fun x -> x >= 10)

// The result is:
// { Included = [10; 354; 234; 23; 45]
//   Excluded = [1; 2; 3] }

We can now rewrite the pseudo-code example above with real code from the Split module:

let finalListOfPersons =
    readListOfPersons()
    |> Split.create filterCriterion1
    |> Split.outputExcluded printer
    |> Split.recreate filterCriterion2
    |> Split.outputExcluded printer
    |> Split.recreate filterCriterion3
    |> Split.outputExcluded printer
    |> Split.outputIncluded printer

The function Split.recreate does a new split on the Included list.

The module also has a number of other functions for manipulating both the Included and the Excluded lists, like Split.sort, Split.map and Split.filter. You can also do things like appending Excluded to Included with Split.merge and swap the two with Split.swap.

Finally can get retrieve Included with Split.decompose.

Here is an example with numbers:

let printer title l =
    printfn "%s: %A" title l

let finalList =
    [ 1; 2; 3; 10; 354; 234; 23; 45 ]
    |> Split.create (fun x -> x >= 10)
    |> Split.outputExcluded (printer "Less than 10")
    |> Split.recreate (fun x -> (x % 2) = 0)
    |> Split.outputExcluded (printer "Odd")
    |> Split.swap
    |> Split.outputExcluded (printer "Even")
    |> Split.decompose

Output is:

Less than 10: [1; 2; 3]
Odd: [23; 45]
Even: [10; 354; 234]

And finalList ends up being [23; 45].

Go ahead, write your code in your native language

Jakob Christensen — Sat, 27 Nov 2021 07:53:50 +0000

Most of us, the developers, probably write our code in English. We name our functions, variables and types in English when we write code, and we write comments, git commit messages and pull request descriptions in English. And it makes perfect sense since English is the number one language spoken by most people in the world. So if we want our code to be read and understood by other people, English is a good choice.

But English is not the number one language in the world when it comes to being the first native language. For many of us, English is a second language used only for communicating with people from other countries. And for writing code. For that reason, many of us learn English in school as part of our education to become citizens of the World.

I have the quite unpopular opionion that in some cases it is perfectly fine to write your code in your native language. I'd even say that it is preferrable for some applications. Not everybody agrees.

Denmark is a small country and there are only about 5.8 million Danes on this planet. We don't even make it on the list of top 100 most spoken languages. Even though Danes have had quite an influence on the English during the Viking Age, you should not expect a whole lot of people to understand your code if you write it in Danish.

So how dare I suggest that we should write code in Danish?

What I am talking about are Line of Business (LoB) applications. That is, applications that you write mostly for internal use to solve some kind of business problem that is specific to your company. I am not talking about libraries you publish on npm or Nuget.

I think in the long run you might be better off if you code LoBs in your native language. You may not agree. I know all my colleagues disagree. We have been discussing this on my team and apparently, I am the only one who thinks it is a good idea. But I stand my ground and let me tell you why:

Everybody on the team are Danish (actually, I'd say that 98% of the entire company are Danish). All our documents including specifications for in-house LoB applications are written in Danish. We speak Danish with each other. Our offices are located in Denmark. The business terms are very specific to Denmark. Some of us are so-so at written English.

So why on Earth would you not write code, git commit messages and pull request descriptions in Danish?

When writing in your native language, there are less misunderstandings and there a is one-to-one relation between the terms used in your specifications and in your code. There are no weird translations between business terms.

The major counter-argument is, that there will be some weird mix of languages at "the boundaries" between your code and whatever framework or 3rd party libraries you use. That is a valid argument. However, overall I believe that the important code, that is the code that implements the difficult business rules, is easier to understand and reason about if it directly relatable to your specifications.

So go ahead, write in your native language for your own good.

Performance for composition in F#

Jakob Christensen — Sun, 07 Nov 2021 22:51:43 +0000

In a previous post I talked about how we at work simplified composition in an F# project because we found that we took a performance hit when we used monadic binds in our code.

I was a bit surprised how expensive the construct was so I wanted to dig deeper into it with this article.

The setup

Composition in F# can take a number of forms. Below we will take a closer look at the simple straight forward pipe (|>) operator and compare it to the Kleisli composition and monadic bind composition operating on the Result type.

In other words, we will compare the following operators:

// Monadic bind
let (>>=) m f =
    Result.bind f m 

// Monadic bind inline
let inline (>>==) m f =
    Result.bind f m 

// Kleisli
let inline (>=>) a b x =
    match a x with
    | Ok v -> b v
    | Error e -> Error e

To test we compose five different functions. All the functions do is copy some data structure:

type Data =
    { Property1: string
      Property2: int
      Property3: DateTime 
      Property4: float
      Property5: decimal }

let processA data = { data with Property1 = "some new string" }
let processB data = { data with Property2 = 100 }
let processC data = ...

let processResultA data = Ok { data with Property1 = "some new string" }
let processResultB data = Ok { data with Property2 = 100 }
let processResultC data = ...

We use function processData for testing |> and processDataResult for testing the compositions that operate on Result.

Now we can create the functions we wish to time:

let withPiping data =
    data
    |> processA
    |> processB
    |> processC
    |> processD
    |> processE

let withBinding data =
    data
    |> processResultA
    |> Result.bind processResultB
    |> Result.bind processResultC
    |> Result.bind processResultD
    |> Result.bind processResulte

let withOperatorWithoutInlining data =
    data
    |> processResultA
    >>= processResultB
    >>= processResultC
    >>= processResultD
    >>= processResultE

let withOperatorWithInlining data =
    data
    |> processResultA
    >>== processResultB
    >>== processResultC
    >>== processResultD
    >>== processResultE

let withKleisli data =
    data
    |> (processResultA
    >=> processResultB
    >=> processResultC
    >=> processResultD
    >=> processResultE)

Note that withBinding, withOperatorWithoutInlining and withOperatorWithInlining are essentially the same but as we will see later there is a difference in performance between them.

Let's also define a function for timing a number of calls to a function f:

let timeFunction f data =
    let sw = Stopwatch()

    sw.Start()

    [1 .. 10_000_000]
    |> List.iter (fun _ -> f data |> ignore)

    sw.Stop()
    sw.Elapsed.TotalMilliseconds

That way we can time 10 million calls to a function like so:

data |> timeFunction withKleisli

To get a smaller variance on those 10 millions calls, let us define a run function that runs timeFunction a number of times and prints the average:

let run f fName =
    let data =
        { Property1 = "some string"
          Property2 = 42
          Property3 = DateTime.Today
          Property4 = 23.2
          Property5 = 23m }

    [1 .. 100]
    |> List.averageBy (fun i -> timeFunction f data)
    |> print fName

Now we can write the final setup:

run withPiping (nameof withPiping)
run withBinding (nameof withBinding)
run withOperatorWithInlining (nameof withOperatorWithInlining)
run withOperatorWithoutInlining (nameof withOperatorWithoutInlining)
run withKleisli (nameof withKleisli)

Granted, the setup is a bit lame but it does give some indication of differences in performance between the different types of composition.

The results are in

They say that an image is worth a thousand words, so here is a graph for you. I set withPiping as index 100, so the graph shows how the other methods compare to withPiping.

It shouldn't come as a surprise that withPiping is the fastest.

I am a bit surprised that withBinding is that much faster than withOperatorWithoutInlining, i.e. the >>= operator.

Kleisli composition is surprisingly slow, but monadic bind is more useful in F# anyways so you would probably not use Kleisli that often.

Code

I put the code on Github if you want to have a look. I created it on .NET 6 RC using the preview of Visual Studio 2022.

t4rzsan / fsharp-performance-testing

Real life performance optimizations in F#

Jakob Christensen — Wed, 20 Oct 2021 03:33:59 +0000

At work we are building our first major F# application. I work at a pension company, and the application is a simulation model to estimate our future liabilities in regards to our policy holders under different scenarios.

The model will run 100 years into the future on at least 100,000 policies for perhaps 6,000 scenaries. So the application needs to be fast!

Bartosz Sypytkowski wrote a great blog on high performance F# code and we deployed some of his advice. Some of it worked and some of it didn't. Remember, when optimizing for performance, you need to test thoroughly whether your changes actually work for the better. One thing that didn't really work for us was changing our types to structs.

Below is a list of what worked for us. It might also work for you 😉

Avoid Single Case Discriminated Unions

This is taken straight out of Bartosz Sypytkowski's blog. It is quite common to wrap your simple types in Single Case Discriminated Unions in F#.

type PolicyId = PolicyId of string

This gives you nice code and better type safety but it kills performance. Instead we settled for unit of measure and typedefs.

[<Measure>] type percent
[<Measure>] type kr // Danish monetary unit

The percent unit is particularly nice as you never again have to ask how to specify it. When you read it with a unit of measure, you intuitively know that you need to put it as 2.0<pct> and not 0.02<pct>. You also know you need to divide by 100.0<pct> every time you use it, otherwise you will end up with a wrong unit.

let savings = 100000.00<kr>
let interestRate = 2.23<pct>
let interestBad = savings * interestRate // <kr*pct>
let interestGood = savings * interestRate / 100.0<pct> // <kr>

Don't use monadic binding

Personally, I am a big fan of Kleisli composition and monadic binds.

Impeachment in a functional way

Jakob Christensen ・ Jan 13 '20

#functional #fsharp

So naturally we started out with a workflow that looked something like this.

let workflow inputParameters policy =
    policy
    |> calculatePremium inputParameters
    >>= calculatePayments
    >>= calculateYield
    >>= calculateNewSavings
    >>= calculateFoo
    >>= calculateBar

Each function had the same type:

calculateFunction: InputParameters -> Policy -> Result<Policy, 'TError>

It was beautiful. It was also slow.

It turned out that almost all of the calculate functions returned Ok and never Error. So we changed the whole thing to simple piping and added a validation function at the end that returns Result. This gave us much better performance:

let workflow inputParameters policy =
    policy
    |> calculatePremium inputParameters
    |> calculatePayments inputParameters
    |> calculateYield inputParameters
    |> calculateNewSavings inputParameters
    |> calculateFoo inputParameters
    |> calculateBar inputParameters
    |> validatePolicy inputParameters

With this we changed the type for each function to:

calculateFunction: InputParameters -> Policy -> Policy

To be fair, I later on found out that we had forgotten to add inline to the >>= operator and that may have had something to do with the bad performance. Which brings me to:

Use inline

Yes, don't forget to add inline to your generic small helper functions and operators 🙄

Only pass needed parameters

As I said above, all our calculate functions had the same type:

calculateFunction: InputParameters -> Policy -> Policy

But we soon found out that not all functions actually used all of InputParameters. InputParameters was quite large and that meant a performance hit for each call. Therefore, we split InputParameters into smaller logically grouped types and changed each calculate function to only take whatever it needed as parameter.

That gave us a small gain on the performance.

Memoize stuff, and consider using Dictionary instead of Map

We added memoization where ever it made sense and it gave us a lot performance wise. Our first try on a memoize function looked like so:

let memoize f =
  let cache = ref Map.empty
  fun x ->
    match (!cache).TryFind(x) with
      | Some res -> res
      | None ->
           let res = f x
           cache := (!cache).Add(x,res)
           res

We found out that using the .NET type Dictionary<,> gave us better performance.

let memoize f =
  let cache = Dictionary<_, _>()
  fun x ->
    let (found,result) = cache.TryGetValue(x)
    if found then
      result
    else
      let res = f x
      cache.[x] <- res
      res

I both implementations originally came from [@dsymetweets] but I have been unable to find the links.

The above memoization works for functions of one parameter only which led us to some "overloads" for functions with more than one parameter. The following functions create memoized versions of functions with 2 or 3 parameters int that they create a tuple from the parameters and memoize based on that tuple:

let memoize2 (f': 'a -> 'b -> 'c) =
    let f = memoize (fun (a, b) -> f' a b)
    (fun a b -> f (a, b))

let memoize3 (f': 'a -> 'b -> 'c -> 'd) =
    let f = memoize (fun (a, b, c) -> f' a b c)
    (fun a b c -> f (a, b, c))

You'd use them like so:

let add x y z = x + y + z
let addMemoized = memoize3 add
let r1 = addMemoized 1 2 3
let r2 = addMemoized 1 2 3 // Result is now cached

This will create extra allocations but we have not found a better way to do it.

Map string types to integers

In our line of business we use a lot of strings to identify business entities, like for example policy numbers and fund IDs. This leads to a lot of comparison of strings which can hurt performance. So we changed all IDs to integers and created dictionaries on the side to look up IDs before and after the calculations where done.

Conclusion

As I said, these optimizations worked for us but they may not work for you. As we start using the model for real, we might even discover that we have to revert some of the things. Specifically, we may one day find out that structs will work better for us.

I don't recommend most of the things we did if your application is a LoB model that does not need to be very high performant. In that case you should value beautiful code over high performance.

The steps above gave us close to 90 percent improvement but it still might not be enough. In that case we still have one more trick up our sleeves: The monster that goes by the name Mutability! :-)

Getting the "nuget" package manager working in Visual Studio 2019

Jakob Christensen — Tue, 01 Jun 2021 06:23:59 +0000

The other day I was working with a collegue on some quick file manipulation with F# interactive (.fsx) in VSCode using the excellent Ionide extension.

We ran into some trouble with Danish letters and encoding and I knew from previously that for reason Visual Studio seems to handle encoding problems in files somewhat better than VSCode. So we decided to try VS instead.

Don't worry, this post is not about encoding 😉

The Problem

However, we did not get very far with VS. We used the new F# 5.0 way of referencing Nuget packages:

#r "nuget: FSharp.Data"

But VS wouldn't let us have our way and it complained:

error FS3216: Package manager key 'nuget' was not registered in
...
[C:\program files (x86)\microsoft visual studio\2019\professional\common7\ide\commonextensions\microsoft\fsharp\Tools]

Intensive searching on the internet provided us with almost no help whatsoever, except for a bit help on Paket's page on fsi integration. Apparently we were the only two people in the world who could not get this stuff working.

The Solution

A bit more searching also revealed that FSharp.DependencyManager.Nuget is required. It is the F# extension manager for Nuget which gives us the coolness of #r "nuget".

That brings us to the final solution:

Install FSharp.DependencyManager.Nuget with nuget.exe.
Copy the file FSharp.DependencyManager.Nuget.dll to the directory mentioned in the error (in our case C:\program files (x86)\microsoft visual studio\2019\professional\common7\ide\commonextensions\microsoft\fsharp\Tools).

That's it. It took us only 2-3 hours to figure that out 🤦‍♂️🤦‍♂️.

I hope this can be helpful to the third person in the world that runs into this problem.

Impeachment in a functional way

Jakob Christensen — Mon, 13 Jan 2020 15:23:32 +0000

Functional Programming (FP) did not really click with me until I saw how it utilizes composition of functions to model pipelines of tasks. Lots of sources on the internet mention immutability and algebraic types as great advantages of FP but it was composition that won me over.

In particular, composition is perfect for describing workflows from the real world.

The impeachment process

I came across such a real world workflow in this article on Axios. The process for impeachment and removal from office goes through a number of steps where each step has two possible outcomes: Either the process terminates or it continues.

The steps are:

Investigation in the House
House vote
Senate trial

Our goal is to model the steps in a way that mimics the terminations and continuations of the process. We also want each step to report the reason for a termination.

The non-functional way

In a non-functional language such as C# there are a number of ways you could model the process. One way would be to let each step throw an exception in case the process should be terminated. In that case the overall code would look something like this:

public void RunImpeachmentProcess()
{
    try
    {
        InvestigateInHouse();
        VoteInHouse();
        TryInSenate();
    }
    catch (Exception ex)
    {
        Log($"The impeachment process stopped: {ex.Message}.");
        throw;
    }
}

It works but it is not very elegant. Exceptions are for exceptional cases and stopping an impeachment process is not exceptional and this way is not very explicit.

Another way would be to let each function return false or true indicating termination or not.

public bool TryRunImpeachmentProcess(out string reason)
{
    if (TryInvestigateInHouse(out reason))
    {
        if (TryVoteInHouse(out reason))
        {
            return TryTrialInSenate(out reason);
        }    
    }

    return false;
}

This also works and it does not look too bad. However, if the number of steps increase above three it will end up as a mess that is hard to follow. There are other variations, for example you could mix in return statements to avoid the triangle of nested if-statement. You may also have to pass information from one step to the next as a parameter which only makes it harder and messier.

The functional way

Enter composition. With composition your code could look something like this (I will be using F#):

let runImpeachmentProcess =
    investigateInHouse
    >=> voteInHouse
    >=> tryInSenate

This is very explicit. The workflow is self-documenting and you can easily see the steps involved.

Let’s see what the implementation looks like. We start with a type that holds the result for a step, whether the process continues or terminates:

type Reason = Reason of string

type ImpeachmentResult<'T> =
| Impeach of ImpeachValue:'T
| DontImpeach of Reason

We could have used the built-in Result type that can be either Ok or Error. Depending on your political standpoint, using Error for ending the impeachment process may not be the correct term so I created my own ImpeachmentResult type.

We now add the >=> (fish-)operator for composing two functions that each return an ImpeachmentResult:

let (>=>) a b x =
    match a x with
    | Impeach v -> b v
    | DontImpeach reason -> DontImpeach(reason)

The operator takes two functions, aand b with the following signatures:

a:'a -> ImpeachmentResult<'b>
b:'b -> ImpeachmentResult<'c>

Hence, the >=> unwraps the impeachment result of function a and feeds it into function b. The parameter x can be of any type and it does not have to be the same type for each step. I.e. each step may return different results. The only requirement is that the next function takes the same type as parameter.

Let’s add dummy implementations for the three steps (I’ll leave the actual implementation as an exercise for the reader). I have added a exitAtparameter of type ExitAtStep to each function to control which step the process should exit at. In the real world you won’t need such a parameter. However, it does show that you can pass parameters from on step to the next, all handled by the >=>operator:

type ExitAtStep =
| None
| Investigation
| Vote
| Trial

let investigateInHouse exitAt = 
    match exitAt with
    | Investigation -> DontImpeach (Reason "Investigation did not find enough evidence")
    | _ -> Impeach exitAt

let voteInHouse exitAt =
    match exitAt with
    | Vote -> DontImpeach (Reason "Less than two-thirds voted for impeachment in House")
    | _ -> Impeach exitAt

let tryInSenate exitAt =
    match exitAt with
    | Trial -> DontImpeach (Reason "Senate trial exonerated the President")
    | _ -> Impeach exitAt

Finally, we get to the workflow function that is a composition of the three steps above:

let runImpeachmentProcess =
    investigateInHouse
    >=> voteInHouse
    >=> tryInSenate

Note that for this example runImpeachmentProcess is a function of type:

runImpeachmentProcess:ExitAtStep -> ImpeachmentResult<ExitAtStep>

Let’s run it:

let run exitAt =
    let result = runImpeachmentProcess exitAt

    match result with
    | Impeach _ -> printfn "Remove from office."
    | DontImpeach (Reason reason) -> printfn "No impeachment for the following reason: %s." reason

If all three steps return Impeach, it will print out “Remove from office”. If at least one of the three steps return DontImpeach, the code will print out the reason for the exited process with the reason for the first function that returns DontImpeach. Subsequent steps will not be called if one returns DontImpeach. Let’s have a look at the output:

run None
// Remove from office.

run Investigation
// No impeachment for the following reason: Investigation did not find enough evidence.

run Vote
// No impeachment for the following reason: Less than two-thirds voted for impeachment in House.

run Trial
// No impeachment for the following reason: Senate trial exonerated the President.

Closing

Composition gives us a very strong tool for creating explicit workflows for our processes. We are able to create a function composed of other functions that each represent a step in the workflow. The code for the composed function is in itself a documentation of what it does because it very clearly shows the steps:

let runImpeachmentProcess =
    investigateInHouse
    >=> voteInHouse
    >=> tryInSenate

I am in no way the inventor of this method. I just applied it to a world (in)famous ongoing process. Please have a look at the following sources:

Today, I passed a 1,000 followers on dev.to 🤗😁🐎🐴😎🍰

Jakob Christensen — Thu, 13 Jun 2019 19:18:20 +0000

I know, I know... it is not all that impressive compared to many others here on dev.to but for me it is a small victory. Allow me to rejoice just a little bit 🙂

Why you shouldn't wear headphones while working

Jakob Christensen — Fri, 07 Jun 2019 20:33:05 +0000

There are lots of good reasons why you’d want to don headphones and listen to music while coding. They block out noise and help you concentrate. There are also a number of compelling reasons why you should not.

Disclaimer: Below is based on my own experience and may not be scientifically correct.

Here are three reasons why you should leave those headphones off:

Increased sensibility to noise : If you wear your noise reducing headphones all the time, eventually the noice free environment will be the new normal for you. It will be much harder for you to concentrate without your headphones.
Missing out on networking : At your workplace your colleagues will be talking, sharing knowledge and joking around. If you are wearing headphones you will miss out and you will create an invisible barrier between you and your peers making it harder for them to involve you.
Hearing loss :This is the most important point. I know I sound like your father but using headphones will dramatically increase the risk of hearing loss and tinnitus and neither can be cured. When I started coding for what seems a very long time ago I would put on my headphones to block away noice and concentrate. Sadly, I now have tinnitus. It is not something that bothers me in everyday life but it gets worse when I am tired or stressed out and then it is very annoying. I know that when you are young you think that you are invincible but please be careful.

Putting on headphones may be a great help if you work in an open office and the noise gets overhand. But please, please please, listen to this grumpy old man, and do it as little as possible

Do you pay for the photos you use as cover?

Jakob Christensen — Sun, 26 May 2019 19:19:26 +0000

I have noticed that lots of you here on dev.to use cover photos on your articles. Do you own or pay for those photos and do you credit the creator? (you should).

What is dev.to's policy on copyrights?

P.S. I only use my own photographs for my articles.

I am old enough to remember COM

Jakob Christensen — Sun, 26 May 2019 10:26:25 +0000

This question by @ben brought me back to the late 1990s where I first started coding professionally (yes, I am that old).

What are you "old enough to remember" in software development?

Ben Halpern ・ May 23 '19 ・ 1 min read

#discuss

I first started coding on my Sinclair ZX Spectrum by a lucky incident (I won in a drawing competition but that is for another story) but my first real job was as a very young actuary fresh out of university at a company that developed systems for pension companies.

Back then the de facto way of building applications on Windows was C++ and COM using Microsoft Visual Studio C++ 6.0.

I had no idea what I was doing when I first started and neither C++ nor COM are for the faint hearted so I was in for a steep learning curve. COM can really be a challenge...

Disclaimer: Everything below is written from memory and my memory is not exactly state of the art. Please bear with me.

COM allows you to communicate between components that can live in the same process or in another process. In some cases you can even use COM to communicate with components on other machines (i.e. Distributed COM).

COM is based on interfaces. If you want somebody else to call your code you have to define an interface for it (similar to interfaces in C#). In C++ you write your interfaces as abstract classes.

But how, you may ask, do you create and object that may or may not live in another process?

That is a good question.

Obviously, you can't just new up an object by calling its constructor. Instead the good ol' Windows API has a special function for creating objects called CoCreateInstance.

This raises a new question: How does CoCreateInstance know where your component lives? This is one of the big WHY?s of COM: You need to register your COM components in the Windows Registry. That's right! You have to register your COM component in the Windows Registry with a unique ID (Guid) and where the dll og exe hosting your component is located.

You can probably already imagine the kind of mess you can run into when trying to mess with the registry whenever you need to deploy new versions.

But how, you may ask, do you clean up objects that may or may not live in another process?

That is a great question.

Naturally, you can't just delete an object that you really don't know where lives.

COM's solution to that is reference counting. Each object keeps an internal count of the number of references that exist to the object. Of course, C++ has no built-in ways of helping the developer with keeping track of references so there are a bunch of rules on how to be a COM developer. The rules dictate when the developer has to manually add or subtract to the reference count. You can do that through the IUnknown interface that every COM component must implement.

If you forget to follow the rules, the memory leaks will start piling up. Here is some pseudo code on how to create a memory leak in no time:

IHorse *p1;
CoCreateInstance(..., &p1);
IHorse *p2;
CoCreateInstance(..., &p2);
p2 = p1; 
// Oops! You forgot to release p2 before reassigning 
// and to increase the ref. count for p1.

Hunting down these kind of memory leaks is a real pain. You practically have no idea where to begin. At the company I worked for we created a special in-memory log for logging reference counting which was a great help and we would also use smart pointers to handle releases automatically. But the pain though... it this makes you really appreciate the garbage collection in modern runtimes.

If you are programming in Swift or Objective-C you may know reference counting as ARC. ARC can get you in trouble but the runtime on Apple devices know about reference counting so it is a lot easier on the developer than COM.

But how, you may ask, do you handle concurrency, when calling objects that may or may not live in another process?

That is a really great question.

Naturally, with objects living in different process you are going to have to worry about concurrency and COM tries to help you with that by putting the objects in "apartments".

Objects that are not thread safe should live in the Single Thread Apartment (STA) and objects that are thread safe may live in a Multiple Thread Apartment (MTA). You have to decide where your object should live when registering it in the registry.

When calling into another apartment your call needs to be serialized by a so-called marshaller. Unless you are insane you want those marshallers to be created automatically which means that you can't write your interfaces in C++. You need to define them in the Interface Definition Language (IDL) that will be transpiled into C++.

As you may suspect by now, COM apartments may you lead you to serious self-inflicted injuries. They should come with a warning. For example, consider the ADODB.Connection type used for connecting to databases.

ADODB.Connection is an STA component, meaning that only one thread is allowed to access the object at the same time. Not all developers were aware of this back in the 2000s so people would put the connection object in the session cache on classic ASP web sites to save time and speed up response times. Of course, sending all requests to a web site through the same thread is usually not a good idea for your response times.

Back then many developers including Microsoft said that VB6 was the answer to all your problems with COM as VB6 would handle the reference counting for you. That is true to some extent but you did not know the internal workings of reference counting you could very easily create memory leaks in VB6 and you would have no idea why!

Closing

One of the gurus of COM back then, Don Box, famously coined the term "COM is love" because of how COM was built on contracts. But I can say for sure that I did not love COM all that much and I do not miss it at all. It only makes me appreciate .NET that much more.

COM is still very much in use today: The Office applications rely heavily on COM. If you want to write a component with functions callable from within Excel cells or from VBA, you need a COM component. Luckily, you can write it in C# and fairly easily register it as a COM component. .NET will create as shim for you that handles the reference counting and all the other good stuff.

Using single case union types for entity IDs in F# and making it work with Dapper

Jakob Christensen — Sun, 12 May 2019 08:47:07 +0000

In C# it is a common and popular pattern to use strongly typed entity IDs instead of using integers or the likes for IDs on your entities. Strongly typed entity IDs is a great help when trying to prevent you from mixing an Order ID with an OrderLine ID.

Andrew Lock recently wrote a series on the topic that you should go read now.

A strongly typed entity ID may look something like this (the example used by Andrew Lock):

public readonly struct OrderId : IComparable<OrderId>, IEquatable<OrderId>
{
    public int Value { get; }

    public OrderId(int value)
    {
        Value = value;
    }

    public bool Equals(OrderId other) => this.Value.Equals(other.Value);
    public int CompareTo(OrderId other) => Value.CompareTo(other.Value);

    public override bool Equals(object obj)
    {
        if (ReferenceEquals(null, obj)) return false;
        return obj is OrderId other && Equals(other);
    }

    public override int GetHashCode() => Value.GetHashCode();
    public override string ToString() => Value.ToString();

    public static bool operator ==(OrderId a, OrderId b) => a.CompareTo(b) == 0;
    public static bool operator !=(OrderId a, OrderId b) => !(a == b);
}

That is a lot of code to write for every ID in your domain model and you should create a code snippet in Visual Studio to do it. However, as with many things you get this more or less for free in F# with single case union types. All it takes is this:

type CarID = CarID of int

F# will give you equal operators and the other stuff for free, hence:

let id1 = (CarID 42)
let id2 = (CarID 42)

id1 = id2 // true

As Scott Wlaschin points out on the legendary F# for fun and profit you can use single case union types for anything, not just IDs:

module Domain =
    type CarID = CarID of int
    type CarMake = CarMake of string
    type Model = Model of string

    type Car = {
        CarID: CarID;
        Make: CarMake;
        Year: int;
        Model: Model;
    }

I am not saying this is always a good idea but don’t take it for any more than an example.

What happens if you try to read a Car from a database with Dapper?

Single case union types and Dapper

Dapper uses reflection to create instances of your entity types either by calling the appropriate constructor or by setting properties. For F# record types you cannot set the properties so Dapper tries to call the constructor when querying the database:

use cn = getConnection ()
let cars = cn.Query<Car>("SELECT CarID, Make, Year, Model FROM Car")

This will fail because Dapper tries to find a constructor on OrderLine with the signature (int * string * int * string).

To help Dapper convert from int to CarID, from string to Make and so on you can register a type handler with Dapper. A type handler is a class that inherits SqlMapper.TypeHandler<>. For reading CarID from the database the type handler would look like this.

type CarIDTypeHandler() =
        inherit SqlMapper.TypeHandler<CarID>()

        override x.SetValue(parameter: IDbDataParameter, value: CarID) =
            ()

        override x.Parse(value: obj) = 
            (CarID (Convert.ToInt32(value)))

You register the type handler with Dapper with SqlMapper.AddTypeHandler(typeof<CarID>, new CarIDTypeHandler()). It gets boring very quickly to write type handlers for every single single case union type you come up with (sorry about that strange sentence) and fortunately there is a way to write a generic type handler for single case union types using reflection.

type SingleCaseUnionTypeHandler<'T>() =
        inherit SqlMapper.TypeHandler<'T>()

        override x.SetValue(parameter: IDbDataParameter, value: 'T) =
            ()

        override x.Parse(value: obj) =
            let cases = FSharpType.GetUnionCases(typedefof<'T>)
            FSharpValue.MakeUnion(cases.[0], [| value |]) :?> 'T

The last line makes use of FSharpValue.MakeUnion to create a union. It assumes that the union type 'T has one and only one case when using cases.[0]. I have not found a way to restrict the generic type parameter to unions.

Now you can register the type handler for all single case union types:

SqlMapper.AddTypeHandler(typeof<CarID>, new SingleCaseUnionTypeHandler<CarID>())
SqlMapper.AddTypeHandler(typeof<CarMake>, new SingleCaseUnionTypeHandler<CarMake>())
SqlMapper.AddTypeHandler(typeof<Model>, new SingleCaseUnionTypeHandler<Model>())

Closing

Above we have seen how we can easily use single case union types for type safe handling of entity IDs and other values to prevent using them interchangeably. We have also created a generic Dapper type handler for single case union types.

The generic type handler is only suitable for cases where you do not need extra logic or validation for creating your single union value types and you should also be careful when it comes to performance issues with the reflection in case you need to handle large amounts of instances.