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.