Category theory can be thought of as being "very abstract algebra". It is thought of as "too abstract" by some people, and as "abstract nonsense" by some others. In this talk I will show that while it is abstract, it is far from being nonsense. I will argue that the abstraction has a purpose and that broad applicability is one of the powerful consequences. To demonstrate this, I will show how I apply concepts of category theory to important questions of life such as prejudice, privilege, blame and responsibility. I will introduce the category theory concepts from scratch so no prior knowledge is needed. These concepts will include objects and morphisms, isomorphisms and universal properties.

Back in the 80's, one approach to compiling functional programming languages was to compile down to combinators such as SKI. John Hughes' initial work on supercombinators changed the way folks thought about compiling functional languages and caused folks to turn away from this approach by customizing the combinator set to your particular program. Then Lennart Augustsson's work on implementing supercombinators more efficiently sealed the deal. GHC's compilation technique is a descendant of this school of thought.

But what did we give up to get to where we are? Let's explore a bit of alternate history.

Functional programming has become inevitable. New programming languages draw inspiration from the functional paradigm; old programming languages retrofit support for functional programming; and development teams change their coding style to adopt the best functional programming idioms. We are clearly experiencing a paradigm shift in our industry.

Due to its academic roots, functional programming sometimes seems unapproachable, with unfamiliar jargon, obscure concepts, and bewildering theories. It doesn’t have to be like that.

In this one-day series of lectures and hands-on workshops, we will translate the jargon, demystify the concepts, and put the theories into practice. There is nothing inherently difficult about functional programming. In fact, its main aim is to simplify programming and to make it more widely accessible. Functional programming is about being able to understand one function without the million lines of code it is a part of. It is about code reuse. It is about modularity and keeping code easy to change and refactor. These are all goals of good program design that every developer appreciates. Based on this common ground, we will explore functional programming together and see how it can help us to achieve these design goals. In fact, by learning the fundamentals of functional programming in Haskell, we can improve program design in mainstream languages, such as Javascript and C++, and even more so, in hybrid languages, such as Scala and Swift.

Throughout the day, we will explain the most commonly used functional programming terminology. You will learn the fundamentals of Haskell, one of the most popular functional programming languages. In the process, we will look at a lot of concrete code to understand what functional programming is all about and how to use it in your own programs. In the workshops, you will have plenty of opportunity to write code yourself, experiment, and ask questions. It’ll be fun!

Bring your laptop and your curiosity and by the end of the day, functional programming will be another tool in your toolbox, and you will be ready to enjoy the main YOW! Lambda Jam conference.

Cursive is an IDE for Clojure, based on the IntelliJ framework. In contrast to the majority of Clojure development environments, Cursive uses static analysis of the source code to work its magic rather than using runtime inspection of a live system via the REPL. IntelliJ provides a sophisticated indexing infrastructure, and this in combination with static analysis allows many interesting features which are difficult or impossible to achieve with a traditional REPL-based environment. Essential code navigation tools such as Find Usages and refactorings such as Rename become possible, and using IntelliJ's code inspections can provide error marking and static analysis of code, right in the editor. This ability to see problems immediately provides an even shorter feedback loop than working in the REPL.

I'll discuss some of the challenges of developing a traditional IDE for a language as flexible as Clojure, including the implementation details of how to deal with syntax extensions from macros. I'll also talk about the various ups and downs of developing much of it in Clojure, and why some of it is also developed in Kotlin. I'll also talk about why I believe our editors should be syntax aware, not just text based.

Have you ever been puzzled by the suggestion that

data Lens s a = Lens { get :: s -> a, set :: a -> s -> s }

might be in some sense the same as

forall f. Functor f => (a -> f a) -> s -> f s/code>

or, more to the point, how on earth someone ever went about figuring this out in the first place?
Don't know your Kan extensions from your co-ends, your pushouts from your presheaves?

Join me for a scenic adventure tour through the magical land of category theory, stopping off at all the major sights.

We'll learn the basic notions that form the conceptual backbone of category theory,
and how they all fit together.

Category theory has made deep inroads into computer science theory, but in this talk we'll be focused on computer science practice. We'll explore the advantages category theory brings to programming in terms of

• providing alternate representations for types
• classifying solutions, or
• simply providing a clarifying viewpoint and helping to organise our thinking.

In addition this should provide you with the right framework for further exploring category theory, should you so wish.

Recursion is used extensively in functional programming. It is indeed iteration through nested data structures. Therefore patterns are identified to generalise the nested structure iteration. Using these patterns can factor out the recursion mechanism from application specific logic for code simplicity. That's the purpose of recursion scheme.

This talk points out different recursion problems are having similar patterns. The recursion scheme is introduced to support these patterns. It will discuss how the common iteration mechanics is separated from the application specific logic by using the patterns, aka morphisms, provided by the recursion scheme. The fundamental pattern, catamorphism, and a few other commonly-used morphisms will be illustrated with some recursion examples.

The aim of the talk is to give audience an idea of how recursion can be implemented in simple and elegant ways by applying the various morphisms provided by the recursion schemes.

Programming generative art, also known as creative coding, is often a trial-and-error process, combining creativity and logic to present something aesthetic. However, creative coding has a high barrier to entry due to the breadth of knowledge and coding skills required. This talk aims to lower that barrier for you to take home and practice creative coding.

In this talk, you will learn about algorithms and techniques for generative art using a pure functional paradigm. First, shepherding random numbers to simulate the universality of nature patterns that appear in plants, rocks, sand, and smoke. Next, using L-system formal grammar to create a seemingly infinite, but well-structured, series of graphics. Lastly, interfacing with printers to bring your drawing to life.

For you to get the most out of this talk, you should be comfortable working in a functional language of your choice. Although I will introduce some theory, background in mathematics and formal theory is not required to attend.

Automated testing is key to ensuring the ongoing health and well being of any software project, giving developers and users confidence that their software works as intended. Property based testing is a significant step forward compared to traditional unit tests, exercising code with randomly generated inputs to ensure that key properties hold. However, both of these techniques tend to be used at the level of individual functions. Many important properties of an application only appear at a higher level, and depend on the state of the application under test. The Haskell library hedgehog, a relative newcomer to the property based testing world, includes facilities for property-based state machine testing, giving developers a foundation on which to build these more complicated tests.

In this talk, Andrew will give you an introduction to state machine property testing using hedgehog.He'll start with a quick refresher on property based testing, followed by a brief introduction to state machines and the sorts of applications they can be used to model. From there, he'll take you on a guided tour of hedgehog's state machine testing facilities. Finally, Andrew will present a series of examples to show off what you can do and hopefully give you enough ideas to start applying this tool to your own projects. The application being tested will be a servant web application, and examples will include testing fundamentals such as content creation and deletion, uniqueness constraints, and authentication.

An intermediate knowledge of Haskell and familiarity with property based testing will be beneficial,but not essential. The slides and demo application will be available after the talk for people to study in detail.

Transducers -- composable algorithmic transformation decoupled from input or output sources -- are Clojure’s take on data transformation. In this talk we will look at what makes a transducer; push their composability to the limit chasing the panacea of building complex single-pass transformations out of reusable components (eg. calculating a bunch of descriptive statistics like sum, sum of squares, mean, variance, ... in a single pass without resorting to a spaghetti ball fold); explore how the fact they are decoupled from input and output traversal opens up some interesting possibilities as they can be made to work in both online and batch settings; all drawing from practical examples of using Clojure to analize “awkward-size” data.

Elixir is a functional language that's growing in popularity as a stepping stone into functional programming, thanks to its strengths in areas like concurrency, fault tolerance and scalability combined with a syntax that is simple to learn, and feels very familiar for those with experience of languages like Ruby or Python. However, it is a very different beast – a functional style, new tools, and Erlang and Elixir libraries to learn, and while many people are experimenting with it, it's not quite mainstream for apps in the wild yet.

Our Elixir journey began around two years ago, when we started breaking out parts of our monolith and rebuilding it as microservices in Elixir. It was a chance to introduce boundaries, and consider performance from the ground up for an application for which performance was starting to become a concern as the customer base was growing. This talk will tell the story of a journey into a new, functional language and discuss how we approached decisions around where to start breaking the monolith apart.

The talk will also cover some of the lessons we learned, including:
- How Elixir’s functional style made us think differently about writing code in other languages
- Moving from ExUnit to Espec and back again
- Tools such as umbrella apps that helped us to work with a group of Elixir microservices
- How we planned for performance from the beginning, and Elixir features that helped us with this such as GenServer
- Deployment strategies for the Elixir applications
- How the migration impacted different team members including front end developers

Time has a profound impact on the complexity of the systems we build.

A significant amount of this software complexity comes from either an
inability to recall previous states or the inability to understand
how a state was arrived at.

From the foundations of AI, LISP and functional programming [1], to
causality in distributed systems [2], to the more grungy practices of
immutable infrastructure, or the unreasonable effectiveness of
fact-based approaches to large scale data systems; the ability to
adequately cope with time, and the change and conflict it inevitable
creates, is a common thread to being able to build and reason about
these systems.

This talk looks at the impact of time on system design. We will walk
through examples of large-scale systems and their battles with
complexity. At the end of the talk, the audience should start to see
the common spectre of time and have an appreciation of how
understanding time is fundamental to maintaining clarity, correctness
and reliability in systems.

[1] Situations, Actions, and Causal Laws
John McCarthy
http://www.dtic.mil/dtic/tr/fulltext/u2/785031.pdf
[2] Times, Clocks and the Ordering of Events in a Distributed System
Leslie Lamport
https://amturing.acm.org/p558-lamport.pdf

Elm, for a long time the flag bearer of Functional Reactive Programming on the web, recently switched to a simpler pure functional architecture, citing 'ease of use'. Those of us that have worked on complex reactive mobile apps can sympathise with this - using FRP injudiciously in your app can make the code difficult to understand and near impossible for new developers to pick up.

So are we able to apply some of the techniques and patterns from Elm into iOS apps? It turns out the Elm architecture is a really great fit for Swift & iOS - it allows us to:

• reserve our FRP hammer for the use cases that make the most sense
• separate out a simple, consistent, and highly testable pure functional core, and
• provide a flexible, yet easily understood & applied set of architectural building blocks.

This session will cover the basics of implementing and using an Elm-style architecture in a Swift app, will include lessons learnt in a real-world implementation, pitfalls/benefits, and implementation considerations should you adopt the approach in your own app.

Since their introduction, Applicative and its sidekick Alternative have become ubiquitous and beloved type classes in Haskell and similar languages such as Purescript. By contrast, their contravariant counterparts are relatively unknown. These contravariant structures are useful, and their time has come!

In this talk, we will learn about Contravariant, and its subclasses Divisible and Decidable. How do they work? How do they relate to the classes we know? Are they useful? For what? This talks aims to demystify these classes in an approachable way, by demonstrating their use with practical motivating examples.

Haskell has a powerful foreign function interface (FFI) for interfacing with C libraries. Haskell is a great language for building libraries and tools, but interoperability requirements or time constraints can make the FFI a compelling option.

Binding to a non-trivial C library presents several challenges including C idioms, memory management, error handling and more. This presentation will address a selection of these concerns, using hs-notmuch, a binding to the notmuch mail indexer, as a case study. We will discuss:

• FFI basics and tools to assist binding authors
• working with "double pointer"-style constructors
• working with iterators; how to do lazy iteration
• how to use Haskell's garbage collector to manage lifecycles of external objects, and "gotchas" encountered
• using types to enforce correct use of unsafe APIs
• performance considerations (including profiling results)

The presentation will conclude with a mention of some important FFI concepts that were not covered (e.g. callbacks) and a look at how hs-notmuch is being used in the Real World.

Developers familiar with C will get the most out of this talk (because there will be limited time to explain C idioms, memory management, etc). To varying degrees, most of the concepts and techniques discussed will apply to other languages' FFIs.

Many people are familiar with Haskell stream processing libraries such as pipes or conduit. However, they can be a bit daunting to newcomers: they contain both input and output types in the same representation and they require all these new operators rather than using well-known function composition.

The streaming library by Michael Thompson takes a simpler approach to represent how to stream data through your code. It offers a more familiar API to anyone used to using lists, whilst still offering a lot of power and flexibility. It also compares very well in terms of performance: conduit's fusion framework tends to use a similar structure!

In this workshop we will have an overview of the streaming ecosystem and how it compares to pipes and conduit, and start using it to efficiently process large amounts of data.

If attending this workshop, you may wish to download the exercises (and fetch any dependencies) beforehand.

attoparsec is a high performance parser combinator library for Haskell. It is designed for ByteString parsing and sacrifices helpful error messages and flexibility in the name of speed. Or so the story goes. It turns out that there is more flexibility in attoparsec than meets the eye.

This presentation will familiarise attendees with attoparsec's internals and the design goals that led to the current implementation. This will provide an understanding of how attoparsec achieves its high performance, how to get the most out of it and constructions to avoid.

Following this, we will discuss two parser use cases:

• reporting the position at which parsing failed (often held to be impossible with attoparsec)
• chunking an input by a fixed delimiter string (the naïve implementation is inefficient)

We will see how attoparsec's internals can be exploited to satisfy these use cases. Along the way, some other interesting parsers will be discovered. We will also discuss how the efficient chunking combinator could be constructed in other libraries. The performance impact of the efficient chunking combinator for MIME parsing in the purebred-email library will be demonstrated.

This presentation assumes familiarity with Haskell syntax and parser combinator library usage. Concepts are applicable in other libraries and languages.

Functional programming is becoming more and more popular each day. It is used to make parts of applications highly testable and reusable. Kotin introduces functional programming mechanisms, but for most programmers, it is still difficult to use them in a smart way. This lecture will show how to use functional programming in Kotlin to make clean and reliable code.