While working on the paper „Evolution of Functional UI Paradigms“, published at the FUNARCH workshop of ICFP 2025, I had a thought about pure functions that I would like to briefly explain here. As an argument in favor of pure functions, functional programmers often cite better testability: pure functions require no complicated test setup or mocks, are deterministic, parallelizable, etc. In tendency, this is certainly correct. Pure functions are often better suited for testing than their impure counterparts. However, this connection is not a neccessary implication in either direction: There are pure functions that are hard to test, and there are impure functions that are easy to test. Thus purity itself cannot be the substance that ensures a piece of program is properly testable. But then what is this substance?

Read on...

On March 13, 2026, BOB, Active Group‘s conference about the best in software development, will take place — once again in Berlin and once again at the Scandic Berlin Potsdamer Platz.

The Call for Contributions is open. Send us your proposal for a talk or tutorial (by November 17, 2025) — the program committee is looking forward to it!

Read on...

This is an English translation of the German version of this post.

Read on...

This post is part of the series on functional software architecture in Kotlin. The first one covered functional validation, and this part is about monads. In Kotlin, these are particularly useful when describing domain workflows that should be separated from the technical logic for executing these workflows - specifically using small domain-specific languages (DSLs).

This episode is about how monads actually work. Kotlin has - like many functional languages - special syntax for this, even though you won‘t find it under the „M-word“ in the documentation. It‘s hidden behind the suspend keyword.

Read on...

This post is the beginning of a series about functional software architecture in Kotlin. Its material originally comes from a collaboration between Active Group and Blume2000, where we consulted them on the development of their web shop. I wrote this post together with Benedikt Stemmildt, who was CTO at Blume2000 at the time.

This post is about data validation. We want to ensure that objects in our program are „valid,“ meaning they satisfy arbitrary consistency criteria without which our software won‘t function.

My colleague Marco Schneider already presented abstractions for this in Haskell in an earlier post.

The same ideas can also be transferred to Kotlin — with some compromises. In this post, we‘ll tackle the topic anew, specifically how we can help an object-oriented perspective using functional techniques. So it‘s not necessary to read the Haskell post. (We still warmly recommend the post, as it particularly describes the concept of Applicative, which is impractical in Kotlin.) However, basic Kotlin knowledge is assumed.

Read on...