Functional Programming has shown the benefits of removing mutation and side-effects, resulting in programs fundamentally simpler and more composable. Nonetheless, many of these programs still rely on applying side-effects to external systems such as databases, file-systems or external services. What happens if we apply these ideas to systems and application architecture, can it make whole systems fundamentally simpler to reason about, build and operate.

Functional approaches to architecture have other key benefits such as being naturally suited to audit and reversion of state to previous versions. They tend to have lower operational risk associated with them. Functional architectures significantly reduce complexity in distributed systems.

This talk looks at the history of systems and applications built with an underlying functional architectures such as journaled file-systems and databases, event sourcing, and content-addressable storage, as well as how these ideas enable.

We’ll see that there is an underlying philosophy of FP that can be brought to most aspects of system design and architecture, even while presenting a mutable face to the world.

Functional Programming has shown the benefits of removing mutation and side-effects, resulting in programs fundamentally simpler and more composable. Nonetheless, many of these programs still rely on applying side-effects to external systems such as databases, file-systems or external services. What happens if we apply these ideas to systems and application architecture, can it make whole systems fundamentally simpler to reason about, build and operate.

Functional approaches to architecture have other key benefits such as being naturally suited to audit and reversion of state to previous versions. They tend to have lower operational risk associated with them. Functional architectures significantly reduce complexity in distributed systems.

This talk looks at the history of systems and applications built with an underlying functional architectures such as journaled file-systems and databases, event sourcing, and content-addressable storage, as well as how these ideas enable.

We’ll see that there is an underlying philosophy of FP that can be brought to most aspects of system design and architecture, even while presenting a mutable face to the world.

Increasingly, people are popping up stating the controversial opinion that names don't matter. To most programmers this statement is obviously untrue, as naming is seen as difficult, and critical to semantic expression and communication in their code. To make matters worse, these same people demand fidelity to obscure and difficult names from mathematics, leading to charges of hypocrisy – if names don't matter, why do they care we all use any particular ones?

We'll try and tease out these seeming contradictions. We'll look at why "names don't matter" is an important idea, and why its more obvious superficial interpretation is specious.