At Unruly, we devote 20% of our time to personal development, via Gold Cards. Benji recently made a good post about what they are and why we do them. Generally, I spend much of my Gold Card time exploring new ideas - getting deeper into functional programming languages, experimenting with porting those ideas into something usable in our tech stack, and so on.

Sometimes, though, I see something about our codebase and think: “I could fix that”. And sometimes it turns out: yes, I can make some significant improvements in just a day! There’s just one problem: we’re all about collaboration, and “fixing” stuff unilaterally is antithetical to that philosophy.

This is the seventh in a series of posts introducing co.unruly.control, a functional control library for Java. Previous parts:

• Most code fails badly
• How to fail in Java
• Carpet-oriented programming
• The difference between functions and methods
• The Applicable Pattern
• Railway-Oriented Programming

I should apologise. In the last post, I cheated slightly.

This is the sixth in a series of posts introducing co.unruly.control, a functional control library for Java. Previous parts:

• Most code fails badly
• How to fail in Java
• Carpet-oriented programming
• The difference between functions and methods
• The Applicable Pattern

Before we start, I’d recommend at least reading Carpet-oriented programming.

So. We’ve got this concept of carpet-oriented programming - of building a pipeline of operations which could fail, sweeping any failures under the carpet, and only thinking about whether it succeeded or not (and what to do about failures) at the end.

One thing this approach lacks is any feedback as to how, or why, it failed.