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.

Three years ago, I quit my job to bet everything on the proposition that Haskell could excel not just for specialized, high-assurance software, but for the kinds of software that millions of engineers work on every day. I had previously built backends with Haskell, with the wonderful experience of code that works reliably, a team that doesn't step on each others' toes, and an ease of refactoring that let us keep the codebase clean without risking regressions. But now, GHCJS and FRP had finally become reliable enough to trust in the real world. It was a game changer: Haskell could now build world-class graphical user interfaces, too, and deploy them as single page web apps — in theory.

In practice, there were many obstacles along the way. However, I found that even with the need to blaze new trails from time to time, our overall pace was far faster than anything I had seen in the imperative tech stacks I'd worked with before. Strong types and pure values decreased bug counts and made code much more readable. Some former backend developers who had scrupulously avoided frontend development told me that they now enjoyed working on the frontend, too.

Since then, I've worked with the community to continue building infrastructure to expand the areas where we can use Haskell to get real work done. Enabling mobile development required bug fixes to GHC, a rearchitected approach to cross-compilation in Nixpkgs, and bindings to native APIs. To scale up to larger projects, we've improved existing tools and created new tools that make developer workflows simpler, faster, and more discoverable. And to make Haskell app development more accessible to beginners and professionals without Haskell experience, we've made more and more functionality available out of the box.

In this talk, I'll show you the tools that are available today and the challenges that lie ahead. I hope you'll come away with a broadened understanding of how Haskell can be applied in your own professional projects — and how the theory of functional programming can be a potent practical tool.

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.

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.

It's hard coming back down to the earth of a JVM based language after spending time with Haskell and OCaml. The type systems are enviable, and the abstractions available are incredibly powerful.

Yallop and White's paper on Lightweight Higher-Kinded Polymorphism has been an inspiration for many libraries seeking to add functional abstractions to languages that don't support them. For Kotlin, one library is [Arrow](arrow-kt.io), which provides incredibly powerful abstractions over native language capabilities like co-routines, reactive-streams and nullable types.

This code jam will demonstrate functional programming in Kotlin with the Arrow library, how the abstractions it provides can improve your code, and how this magic that provides higher-kinded types works under the hood.

There are often two barriers to entry for those who have heard that they "should" look at some category theory. One is the motivation: why is something so abstract going to be helpful? The other is technical: many introductory texts assume a large amount of mathematical knowledge in avance. My keynote talk addresses the first issue and this workshop will address the second. We will introduce some of the basic concepts of category theory without using other mathematical structures as examples. We will cover categories and functors and will also take requests.

There has been a lot of excitement about Functional Reactive Programming (FRP).

Most of it has been about distant relatives of the original idea, which are nowhere near as powerful or as useful.

The `reflex` library -- and the companion `reflex-dom` library -- were created in order to use FRP to do front-end development using Haskell.

This workshop will give you hands-on experience with these libraries.

The workshop will show attendees a new way to manage state and time-dependent logic, with significant benefits over the standard approaches when it comes to abstraction, composition and correctness.

It will also make the case that when these ideas are applied to front-end development, they lead to something beyond what is delivered by libraries like `react` and `redux`.

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.

Let's Lens presents a series of exercises, in a similar format to the Data61 functional programming course material. The subject of the exercises is around the concept of lenses, initially proposed by Foster et al., to solve the view-update problem of relational databases.

The theories around lenses have been advanced significantly in recent years, resulting in a library, implemented in Haskell, called lens.

This workshop will take you through the basic definition of the lens data structure and its related structures such as traversals and prisms. Following this we implement some of the low-level lens library, then go on to discuss and solve a practical problem that uses all of these structures.

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.

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.

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.

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.

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.

Git is the most widely used version control tool today, but what is actually happening when we perform a `git add` or a `git commit`? To answer this question I'm going to walk through a small implementation of Git in Haskell. Along the way we'll touch on functional data structures, content-addressable stores, and parser combinators. At the end we'll analyse an entire Git repository and talk about the practical applications and limitations of what we've built. My hope is that this knowledge will help you be less frustrated the next time you see a cryptic Git error message!

Handling errors in a principled manner is an important aspect of writing production code. Drawing on our experience of writing production systems in Haskell, we believe that for a large class of problems, using the EitherT monad transformer is a simple and effective pattern to handle errors. We suggest that often, several mechanisms for error handling appear in code bases (including exceptions and the use of free monads) and that it will be of interest to intermediate Haskellers to see a principled approach that only uses EitherT to accomplish this.

In this talk, we discuss the design and implementation of "Flax", a purely functional wrapper around the Selenium web testing library. Flax is written in Scala and allows you to create web tests within an "Action" Monad. By making use of Scala's for-comprehensions, Flax tests read like a set of test instructions, but with the benefits of a functional approach.

The talk describes Flax's Action Monad in detail, showing how it is a stack of Either, Reader, Writer and Task. Each of these effects has a specific purpose in Flax's use as a tool for constructing browser-based tests.

Initially, in Flax, we wanted to just do something quick-and-dirty - FP is nice, but for a testing library, do we really need it? However, a number of design problems quickly arose. We'll talk about these issues and how we realized that the purely functional approach was the only sensible way forward.

A key problem we encountered with the functional approach was that we no longer able to use stack traces to identify where a test failed. To address this, we used the Writer Monad to track the actions performed. The actions are tracked as a tree of operations, which lets us group higher-level actions as a tree of lower-level actions. This is particularly useful for structuring browser tests, as often a specification of desired behavior can translate into a long sequence of individual steps.