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. This talk looks at applying these ideas to systems architecture, and how it can make whole systems fundamentally simpler to build, operate and reason about.

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.

This talk looks at the history of systems built with an underlying functional architectures such as journaled file-systems and databases, event sourcing, and content-addressable storage, as well as the application of these ideas in programs such as Lucene and git.

We’ll show 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, like Object Oriented and Structured Programming, is a quite radical departure from previous programming practices. Like these two previous changes in approach, change is gradual and faces significant resistance.

While the ideas around functional programming are becoming more widely accepted, actually adopting the techniques in old-school imperative teams and code bases presents significant challenges technically, culturally and politically. Exploiting the full potential of FP does require experience, and when the imperative experience vastly outweighs that of FP, importing experience can be enormously beneficial.

This talk is about experiences introducing functional programming across a large organisation; what works and, perhaps more importantly, what doesn’t. It looks at some specific patterns and anti-patterns that should be considered for people wanting to transform any organisation that has significant existing program assets and software engineering teams. It will help form and present discussion and arguments to achieve meaningful change.

Many applications face the problem of communicating to external processes via stateful connections, for instance JDBC connections to databases, or SSH connections to a network server. Traditional manual connection handling a la JDBC places all the management burden on the client code, and is error prone.

For a recent project we designed – with prudent use of the Reader, Free and IO monads – a superior API that prevents misuse. This talk explores the evolution of this API and the challenges it presented and solved.

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. This talk looks at applying these ideas to systems architecture, and how it can make whole systems fundamentally simpler to build, operate and reason about.

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.

This talk looks at the history of systems built with an underlying functional architectures such as journaled file-systems and databases, event sourcing, and content-addressable storage, as well as the application of these ideas in programs such as Lucene and git.

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, like Object Oriented and Structured Programming, is a quite radical departure from previous programming practices. Like these two previous changes in approach, change is gradual and faces significant resistance.

While the ideas around functional programming are becoming more widely accepted, actually adopting the techniques in old-school imperative teams and code bases presents significant challenges technically, culturally and politically. Exploiting the full potential of FP does require experience, and when the imperative experience vastly outweighs that of FP, importing experiences can be enormously beneficial.

This talk is about experiences introducing functional programming across a large organisation; what works and, perhaps more importantly, what doesn’t. It looks at some specific patterns and anti-patterns that should be considered for people wanting to transform any organisation that has significant existing program assets and software engineering teams. It will help form and present discussion and arguments to achieve meaningful change.

This talk covers 3 different functional programmers’ experiences applying Functional Programming in industrial settings; A product company improving their process and success, a new team with new projects, and a team performing experiments with multiple implementations using FP and non-FP languages. There have been some impressive results, and some interesting challenges. We hope these stories inform and inspire you if you are interested in adoption FP in your organisation.

Team 1: A new project, and a new team, is theoretically an ideal time to start using functional programming – green fields. Michael had to good fortune to be a co-founding engineer where the teams were built from the grown up, and projects split off organically. Hyper-small teams (1 or 2 people) and FP (Scala and Erlang, mainly) with the so-called micro-services approach allowed this to work – and scale reasonably well as teams grew. There have been trade offs, but using FP has enabled a breadth of features to be implemented via very small teams. Michael will talk about these trade offs and benefits as his portion of the talk

Team 2: ThoughtWorks has been engaged by IOOF to assist them in building superannuation integration solutions. Korny will talk about how ThoughtWorks and IOOF ran an initial three week experiment to evaluate functional programming languages, using a range of objective and subjective metrics. Based on the results of that experiment, the team developed their integration system in Clojure – Korny will also talk about how the adoption went, and how Clojure was a key factor that allowed them to meet tight deadlines in spite of multiple requirement changes.

Team 3: Atlassian products have to run in all manner of environments, with tens of thousands of customers running every possible combination of hardware, OS, DB and more. Functional programming techniques have proved useful to tame the complexity, and now serious FP projects are underway and gaining momentum. Jed relates the challenges, the pitfalls and the successes that have come with introducing FP to Atlassian.

One of the scenarios described is likely to apply to you – we hope you can take this experience back to your organisation and look at ways you can introduce functional programming based on these lessons learned.

This talk covers 3 different functional programmers’ experiences applying Functional Programming in industrial settings; A product company improving their process and success, a new team with new projects, and a team performing experiments with multiple implementations using FP and non-FP languages. There have been some impressive results, and some interesting challenges. We hope these stories inform and inspire you if you are interested in adoption FP in your organisation.

Team 1: A new project, and a new team, is theoretically an ideal time to start using functional programming – green fields. Michael had to good fortune to be a co-founding engineer where the teams were built from the grown up, and projects split off organically. Hyper-small teams (1 or 2 people) and FP (Scala and Erlang, mainly) with the so-called micro-services approach allowed this to work – and scale reasonably well as teams grew. There have been trade offs, but using FP has enabled a breadth of features to be implemented via very small teams. Michael will talk about these trade offs and benefits as his portion of the talk

Team 2: ThoughtWorks has been engaged by IOOF to assist them in building superannuation integration solutions. Korny will talk about how ThoughtWorks and IOOF ran an initial three week experiment to evaluate functional programming languages, using a range of objective and subjective metrics. Based on the results of that experiment, the team developed their integration system in Clojure – Korny will also talk about how the adoption went, and how Clojure was a key factor that allowed them to meet tight deadlines in spite of multiple requirement changes.

Team 3: Atlassian products have to run in all manner of environments, with tens of thousands of customers running every possible combination of hardware, OS, DB and more. Functional programming techniques have proved useful to tame the complexity, and now serious FP projects are underway and gaining momentum. Jed relates the challenges, the pitfalls and the successes that have come with introducing FP to Atlassian.

One of the scenarios described is likely to apply to you – we hope you can take this experience back to your organisation and look at ways you can introduce functional programming based on these lessons learned.

This talk covers 3 different functional programmers’ experiences applying Functional Programming in industrial settings; A product company improving their process and success, a new team with new projects, and a team performing experiments with multiple implementations using FP and non-FP languages. There have been some impressive results, and some interesting challenges. We hope these stories inform and inspire you if you are interested in adoption FP in your organisation.

Team 1: A new project, and a new team, is theoretically an ideal time to start using functional programming – green fields. Michael had to good fortune to be a co-founding engineer where the teams were built from the grown up, and projects split off organically. Hyper-small teams (1 or 2 people) and FP (Scala and Erlang, mainly) with the so-called micro-services approach allowed this to work – and scale reasonably well as teams grew. There have been trade offs, but using FP has enabled a breadth of features to be implemented via very small teams. Michael will talk about these trade offs and benefits as his portion of the talk

Team 2: ThoughtWorks has been engaged by IOOF to assist them in building superannuation integration solutions. Korny will talk about how ThoughtWorks and IOOF ran an initial three week experiment to evaluate functional programming languages, using a range of objective and subjective metrics. Based on the results of that experiment, the team developed their integration system in Clojure – Korny will also talk about how the adoption went, and how Clojure was a key factor that allowed them to meet tight deadlines in spite of multiple requirement changes.

Team 3: Atlassian products have to run in all manner of environments, with tens of thousands of customers running every possible combination of hardware, OS, DB and more. Functional programming techniques have proved useful to tame the complexity, and now serious FP projects are underway and gaining momentum. Jed relates the challenges, the pitfalls and the successes that have come with introducing FP to Atlassian.

One of the scenarios described is likely to apply to you – we hope you can take this experience back to your organisation and look at ways you can introduce functional programming based on these lessons learned.

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.

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.