Haskell has seen success in commercial environments, with teams of professional engineers choosing it for its claims of reliability, a rapid development pace, and easier maintenance over the long term. On top of that, a large community of hobbyist tinkerers and academic researchers are always releasing new and exciting abstractions, libraries, and language extensions, each offering improved ways to structure, build, and test our programs.

Engineering teams have diverse knowledge and skill levels, and new team members need to come up to speed to work effectively. This poses us a challenge: which abstractions, libraries, and language extensions should we choose from the ever-growing pool? How should we determine what level of Haskell to adopt? Should we always embrace the cutting-edge to squeeze out every advantage, leaving new hires in the dust? Should we reject novelty and focus only on the “simple” or “boring” ways of doing things, even if doing so gives up some potential effectiveness?

This talk will bring clarity to these questions. Rather than prescribe a uniform solution, we offer you the tools of thought to make informed, intentional decisions, and cultivate an engineering dialect that works for you.

Functional programmers love to steal ideas from mathematics. Perhaps the best example of this is the venerable monoid, a concept from abstract algebra. But what about other algebraic structures? Semigroups and semilattices, related to monoids and beloved by mathematicians, are also ripe for use by programmers. We will explore these abstractions, their uses, and familiar concretions that fit. We’ll also look at the trade-off that helps us choose which is the right algebraic structure for the job.

Functors are ubiquitous in modern strongly-typed functional programming. Every Haskell beginner will come across them as one of the first typeclasses introduced. Stronger structures such as Applicative and Monad often steal the spotlight, but there are many structures related to the humble Functor that go unnoticed. The goal of this talk is to show off and give an intuition for some of these other structures: contravariant functors, bifunctors, and profunctors. With some of these making their way into Haskell’s standard library recently, now is a perfect time to be introduced to or brush up on these concepts. Code examples will use Haskell, but these techniques extend to any language with typeclasses or a similar mechanism, such as Scala’s implicits.

This talk looks at how functional programming has been used in tertiary education, and how it could be used in the future.
In 1985, Abelson and Sussman's course Structure and Interpretation of Computer Programs made enduring contributions to the art of educating programmers. How to Design Programs later refined some of these ideas, with a new emphasis on decomposing problems and designing solutions. I argue further improvements could be made. In particular, by using a typed functional programming language like Haskell.

This talk will suggest approaches and recommend resources that could be used in the modern education of undergraduate programmers. Such recommendations are also applicable to industry programmers looking to learn functional programming or organisations looking to develop internal training material.

Laws, laws, laws. It seems as though whenever we learn about a new abstraction in functional programming, we hear about its associated laws. Laws come up when we learn about type classes like Functors, Monoids, Monads, and more! Usually laws are mentioned and swiftly brushed past as we move on to examples and applications of whatever structure we're learning about. But not today.

In this talk, we'll learn about Functors and Monoids, paying close attention to their laws. Why should our abstractions have laws? We'll answer this question both by seeing powers we gain by having laws, and by seeing tragedies that can befall us without laws.

From CSV, to JSON, to YAML, DER, and the dreaded XML, many programmers are dealing with data formats all day. In statically-typed languages like Haskell, we can get a great benefit by imposing a rigid structure of types on the data we consume from these formats. We call this process of imposing structure on data "decoding".

Decoding libraries are available in many languages and for many formats. This talk explores the design decisions behind a new Haskell library, sv, which decodes CSV and similar formats such as PSV. sv addresses what we perceived as problems with other libraries. We will discuss the benefits and drawbacks of the interesting or noteworthy choices made in sv's philosophy and design, and make recommendations as to how these lessons could be applied to other formats.

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.