One reason programming is hard is because it is so difficult to observe what is happening when a program runs. Programming languages and libraries rely on abstractions which either hide important details or produce too much information to consume. Developers come to depend on ever-more-sophisticated tools to examine programs and diagnose failures. However, with a little care and design, it is possible to build systems which lend themselves to easier comprehension. This talk will introduce some general guidelines for designing systems which make their data and abstractions more transparent to developers, using code examples in Clojure.

Is functional programming just the result of clever language design? Are there deeper reasons for the effectiveness of the paradigm? Why has functional programming not caught on earlier?

In this talk, we will have a look at the roots of functional programming, at their contribution to the success of the paradigm, and at the lessons we can draw to maximise the benefit we derive from functional languages. I will argue that the core of functional programming is a principled approach to software design compatible with both rigorous and agile methods of software development. It stems from a desire for purity, composability, and elegant logical properties, and I will outline how to leverage these ideas to solve practical programming problems.

Memoization is a technique that allows programs to trade memory usage for improved runtime performance. This is achieved in Haskell by using lazy data structures. However, they should have no effect but to improve the performance making their effectiveness difficult to test and verify. Examples of lazy evaluation, thunks, and the issue of “space leaks” will be given.

In this talk we give an overview of our Kiama language processing library (https://code.google.com/p/kiama/) for Scala. Kiama-based programs use high-level domain-specific languages to describe structured input for parsing, static analysis of programs via attribute grammars, program transformation via rewriting, and output using pretty printing. We describe how Kiama works and illustrate some typical language processing tasks by implementing a version of the lambda calculus, the prototypical functional programming language.

“Starting a new company or a new major project can be a great time to start fresh with FP. Unfortunately starting is often the hardest time to take on anything novel (other than of course, the product itself!) due to perceived additional risk. The reality, however, is that systems will be built quickly, thrown away, re built, hacked on, abused and more. One of the nice side effects of FP (pun intended) is that programs are often brief – you don’t feel as bad throwing them away! At CloudBees we ended up with a mix of Scala and Erlang, with some Clojure thrown in. Almost none of this was by design (from acquisitions and mergers), but has worked out well. The biggest enabler of this has been the proliferation of micro services – at their core, service endpoints can often be thought of a functions – and if the functions are kept pure – then that allows these services to be composed (far more so than if impure) into other services in novel ways. We have also experienced benefits of shedding object oriented ideas in favour of the rigour decomposing something into sensibly named and small functions, with fewer places for state to hide. This talk will go through some of our experiences and systems, including how developers new to FP were able to pick up the smaller systems and run with them over time, and how FP ””risk”” is minimal compared to all the things that can and do go wrong elsewhere.”

In this talk we give an overview of our Kiama language processing library (https://code.google.com/p/kiama/) for Scala. Kiama-based programs use high-level domain-specific languages to describe structured input for parsing, static analysis of programs via attribute grammars, program transformation via rewriting, and output using pretty printing. We describe how Kiama works and illustrate some typical language processing tasks by implementing a version of the lambda calculus, the prototypical functional programming language.

Pattern matching is widely used in functional languages to support ‘programming by cases.’ Common patterns such as tuples and discriminated unions are usually built into the language, but with F# active patterns you can extend pattern matching with your own classification and destructuring logic, capturing chains of if-else-else logic in a readable, reusable abstraction.

In this talk, we’ll take a tour of the various active pattern techniques available in F#, including cases, conditions and parameterised patterns. We’ll explore how to define each kind of active pattern, how to use it in a match expression and where you might apply it in your code.

core.typed is a gradual type system for Clojure. With annotations, it can type check normal Clojure code and help document subtle type invariants. This talk is an overview of core.typed, including its influences, rationale, design goals and tradeoffs. Assumes some experience with Clojure, does not assume core.typed experience. Intended to precede the core.typed workshop

Argonaut is a purely-functional library for dealing with JSON in Scala. Argonaut utilises advanced functional programming techniques that emphasise correctness and performance without sacrificing convenience. Argonaut provides zippers and lenses for efficient navigation and modification of immutable data structures; type-class based codecs for robust, composable mappings between Scala data structures and JSON; and data-types for accurately capturing the essence of JSON and the errors that can occur.

In this talk we will take a look at general principles for designing robust, purely functional libraries in Scala. We will then be taking a deeper technical dive into the specifics of Argonaut, examining the abstractions it uses, the specifics of how they are applied and why these techniques are invaluable to quality code.

Learn about GADTs and nested data types, and how you can use them to encode structural invariants in your Haskell types. You’ll also gain some insight into the inner workings of efficient functional data structures.

In the talk, I’ll show a B-tree, using a GADT to maintain balance. We’ll see that types not only guard against errors, but help us find the right implementation.

Web development in Haskell is efficient, contorting, rewarding, frustrating and elegant all at the same time. 12 Months building production quality Haskell has taught many lessons, and in this talk we will discuss the amazing, with the downright painful, and hope to provide a glimpse at what it is like building real software in a purely functional world.

We will look at the Haskell eco-system and tools; Yesod and the other technologies used to build ApiEngine; as well as the social side of Haskell development by looking at what it takes to spin up new developers.

The term zipper is a colloquial used to describe n-hole (most often, 1-hole) contexts. That is, a data structure that has a hole or pointer focused on a specific element with the ability to efficiently traverse to its neighbouring elements, providing an elegant solution for the need to efficiently traverse and modify immutable data structures. Comonads, the categorical dual of Monads, provide an abstraction for dealing with types that allow extraction. That is, the ability to take a value out of a context; for example, the fact that it is a total operation to extract the head of a non-empty list.

In this talk, we will dive into the implementation of purely-functional data structures in Scala. Exploring zippers, Comonads, and their relationship.

Developers are often very good at spotting repetition in their programs at the value level, but for some reason struggle, or are reluctant to apply that same careful analysis at the type level. This talk aims to build up an intuition for spotting when you can factor your types, examining what this gains you and looking at the practicalities for doing so in Scala. For appropriate buzz-word compliance during this talk you will see Scalaz, Monads, Monad transformers, data types and type classes.

Argonaut is a purely-functional library for dealing with JSON in Scala. Argonaut utilises advanced functional programming techniques that emphasise correctness and performance without sacrificing convenience. Argonaut provides zippers and lenses for efficient navigation and modification of immutable data structures; type-class based codecs for robust, composable mappings between Scala data structures and JSON; and data-types for accurately capturing the essence of JSON and the errors that can occur.

In this talk we will take a look at general principles for designing robust, purely functional libraries in Scala. We will then be taking a deeper technical dive into the specifics of Argonaut, examining the abstractions it uses, the specifics of how they are applied and why these techniques are invaluable to quality code.

Many people recognise the value of Functional Programming, but there are always barriers to getting it adopted in the workplace. In this talk I will cover the approach we took to introduce functional programming at a financial services company.

We ran a 3 week exercise, developing a small part of our business requirements in parallel in Scala, Clojure and Java. I will discuss our methodology, our results (both objective and subjective), and the eventual outcome.

Parts of this exercise worked very well, and parts worked rather less well – I’ll also talk about what can be learned from our mistakes, and how others might try to vary our approach in their workplace.

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.

Erlang is a language designed for building highly concurrent, highly available systems. And, based on our experience using it to build a large-scale VoIP soft-switch, it does a great job of this.

However…every language has a collection of “gotchas” which developers often don’t discover until they’re neck-deep in building a big system. If they’re really lucky, they’ll discover them before the users do.

I love Erlang as a language, but in this respect it’s no different from any others. This talk aims to briefly cover the things it would have been nice to have known before we ran head-long into them such as:

• How to crash your VM (and how not to)
• Message queues: they’re not magic
• Why you can’t just run Erlang as a Unix-style service (and how you can)
• Hot Code Loading: not as easy as you might hope
• The OTP: Forget everything they taught you in the first Erlang lesson
• System monitoring is even more important than you think

Array fusion is an approach to writing numerical code that allows the program to be written in terms of high-level bulk array combinators (map, fold, filter etc) but then compiled down to efficient object code. If done correctly, the resulting code can run as fast as hand written loops expressed in imperative languages. Repa-style array fusion is one method that also provides parallel evaluation without the programmer needing to write anything extra to enable it. In effect, array fusion converts the program you want to write into the one you want to run. I’ll discuss how Repa-style array fusion works, covering enough technical detail so that client programmers can reliably get good performance out of their own programs. I’ll also discuss the limitations inherent in the fusion model, to give a feel for how much performance can reasonably be expected.

A completely re-designed collections API was released for Scala 2.8 in 2010. Among it’s innovative features were highly polymorphic methods (e.g. map) whose static types varied in a rich, context-dependent fashion. The technique employed was based upon multi-parameter typeclasses, which interact with the type-inference process. The initial reception was uncertain: what Odersky described as “a new kind of polymorphism”, some Scala users – disturbed by the increased API complexity – described instead as “the longest suicide note in history”. It took another year for Miles Sabin to note the technique had precedent in Haskell, where it was called Functional Dependencies. This talk will explain the technique, and show how it can be useful in applications beyond the Collections API.

Slides and code are available here: https://github.com/benhutchison/TypeclassDrivenPolymorphism

Whatever the system you’re working on it can probably be thought of as a living organism. You nourish it, extend it, add new abilities and inevitably it will depend on external factors to operate properly.

It’s not uncommon for systems to have multiple dependencies on external services. This communication sometimes goes both ways – as well as being asynchronous a lot of the time – and appropriate actions should be taken when certain ‘events’ happen.

The way in which these ‘events’ are handled can be the difference between a clean, easy to reason about codebase and a tangled mess. Who never got stuck in callback hell?

Functional Reactive Programming provides better abstractions in such scenarios.

It models your system’s behaviors as streams of values that change over time. In a functional setting, this allows streams to be filtered, mapped over, sampled, reduced and composed in a number of ways much like you compose pure functions.

In this talk you’ll learn what’s in it for you: how you can use FRP, what’s its sweet spot as well as what tools are available to you.

Make sure you bring a laptop with a working Clojure development environment. By that I mean at least two things:

• Leiningen 2.x: https://github.com/technomancy/leiningen
• Your favourite Clojure editor: Emacs, vim, La Clojure (IntelliJ plugin), Counterclockwiste (Eclipse plugin) or any other editors you like