This is the fifth in a series of posts introducing co.unruly.control, a functional control library for Java. You can find the introductory post here, a critique of different ways to represent failure here, an an overview of carpet-oriented programming - abstracting control flow with Optionals - here, and an argument for implementing rich behaviour on datatypes using standalone functions instead of methods here.

So. You’re on board with using functions instead of methods, and you start applying that approach. Most likely, you’ll find that your code is bitty and clunky - it just doesn’t flow like it did when you were happily chaining methods.

Let’s explore that.

Functions? More like clunk-tions!

Using functions instead of methods looks fine in isolation, but the moment you want to do something more complex - like building a carpet-oriented programming pipe - the functional approach starts to get much harder to read.

This is the fourth in a series of posts introducing co.unruly.control, a functional control library for Java. You can find the introductory post here, a critique of different ways to represent failure here, and an overview of carpet-oriented programming - abstracting control flow with Optionals - here.

Java 8 introduced Optional, along with lambdas and method references. There was quite a lot of debate on its API - some wanted it to be just a null-safe container, whereas others lobbied for methods like map() and flatMap().

Getting the API right for foundational types like Optional is really hard. Too many capabilities and the clarity of purpose is obscured; too few and you miss opportunities for powerful constructs.

Optional got it wrong in both directions: it has methods it shouldn’t, and it doesn’t have methods it should. This is a near-unavoidable consequence of a fundamental design mistake: the API of Optional is made of methods instead of functions.

This is the third in a series of posts about co.unruly.control, a functional control library for Java. You can find the introductory post here, and a critique of different ways to represent failure here.

Before we look at railway-oriented programming with Result, it’ll help if we start with the similar, but simpler case of carpet-oriented programming with Optional. And we’ll illustrate this with the King of Spain’s Beard.