Predictable Randomness: Part 1

Episode #47 • Feb 18, 2019 • Subscriber-Only

Let’s set out to make the untestable testable. This week we make composable randomness compatible with Swift’s new APIs and explore various ways of controlling those APIs, both locally and globally.

Predictable Randomness: Part 1
Introduction
00:05
Gen recap
01:12
Gen modernization and clean-up
03:38
Taking Gen for another spin
09:26
Controlling Swift's randomness API
16:41
Controlling with Environment
21:03
To be continued…
31:46

Unlock This Episode

Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.

Introduction

Previously on Point-Free we spent several episodes exploring the topic of randomness. It’s a topic that seems at odds with functional programming. We like to work with functions that take data in and spit data out in a consistent fashion, but randomness is all about inconsistency!

Despite this seemingly irreconcilable difference, we found that a randomness API deeply benefited from functional programming principles, specifically composition. We were able to distill the idea of randomness into a single type that could be transformed and combined using familiar functional concepts, and we ended up with a little library that was much more flexible and extensible than the randomness APIs that ship with Swift.

But even though we built this library around functional principles, it’s far from functional. We’d be remiss to ignore the fact that it’s completely unpredictable and untestable, and any code that uses it becomes immediately unpredictable and untestable as a result! One of the things we value in functional programming is the ability to reason about our code using predictable units that can be easily tested, so today we’re going to do something about it: we’re going to make the untestable testable.

This episode is for subscribers only.

Subscribe to Point-Free

Access this episode, plus all past and future episodes when you become a subscriber.

See plans and pricing

Already a subscriber? Log in

References

SE-0202: Random Unification

Alejandro Alonso • Friday Sep 8, 2017

This Swift Evolution proposal to create a unified random API, and a secure random API for all platforms, was accepted and implemented in Swift 4.2.

Composable Randomness

Brandon Williams & Stephen Celis • Monday Sep 17, 2018

The Gen type made its first appearance in this episode bridging function composition with randomness.

Randomness is a topic that may not seem so functional, but it gives us a wonderful opportunity to explore composition. After a survey of what randomness looks like in Swift today, we’ll build a complex set of random APIs from just a single unit.

Dependency Injection Made Easy

Brandon Williams & Stephen Celis • Monday May 21, 2018

We first introduced the Environment concept for controlling dependencies in this episode.

Today we’re going to control the world! Well, dependencies to the outside world, at least. We’ll define the “dependency injection” problem and show a lightweight solution that can be implemented in your code base with little work and no third party library.

Allow Error to conform to itself

John McCall • Wednesday Dec 5, 2018

Swift 5.0 finally introduced the Result type to the standard library, and with it a patch that conforms Error to itself, allowing Result’s Failure parameter to be constrained to Error in an ergonomic fashion. While this conformance is a special case, Swift may automatically conform certain protocols to themselves in the future.

A Little Respect for AnySequence

Rob Napier • Tuesday Aug 4, 2015

This blog post explores the need for AnySequence in Swift as a pattern for working around some of the shortcomings of protocols in Swift.

Type Erasure in Swift

Mike Ash • Friday Dec 8, 2017

This edition of Friday Q&A shows how type erasure can manifest itself in many different ways. While you can wrap the functionality of a protocol in a concrete data type, as we explored in our series on protocol witnesses, you can also use subclasses and plain ole functions.