This isn't how linguists and cognitive scientists think of metaphor, however. Decades of research into the nature of metaphor suggests that conceptual metaphors are pervasive, and much of our reasoning power and ability to build and understand abstractions is based on metaphor. Some of these conceptual metaphors, such as understanding and talking about time, by relating it to properties of physical space, are "dead" to us; that is, we no longer feel that they are metaphors, but it's difficult to think of "time" without those metaphors. Some, such as "time is money", are more obviously metaphorical but influence our unconscious understanding of time and what we think about it.

We'll examine the necessity of conceptual metaphors and what makes metaphors good or bad, in what they conceal or reveal about things and their relationships. We'll look at the ways mathematics relies on metaphor, and the metaphorical nature of how we think about computers, programs, interfaces -- and, yes, monads. Finally, with an eye toward better pedagogy and building better interfaces, we'll see how finding new metaphors can help us see new truths about the world by revealing facets of abstractions that other metaphors have concealed.

At QFPL, we're big fans of the `reflex-frp` framework for functional reactive programming. It is great for what would otherwise be hairy and complicated user interfaces, not to mention handling convoluted application behaviour. With the core `reflex` and `reflex-dom` packages you have access to an incredible amount of high-performing functionality.

But there was a gap... The was no nice way to integrate with some of the more powerful drawing APIs present in a modern browser. Specifically SVG and Canvas.

• To render SVG elements you had to type them all out by hand as custom elements, with no guide as to which properties belong where.
• To use the Canvas you had to dig into the JavaScript FFI and figure out how to wire in the require actions.

The original paper on functional reactive programming was specifically for functional reactive animation. But we didn't have a nice way of building animations using FRP! No longer!

Content

We'll use these libraries to generate some art, then make them wiggle and dance to various inputs! Starting with some SVG drawing using a blog post by Benjamin Kovach as a guide. After that we'll switch over to the 2D HTML5 Canvas, followed by some WebGL GLSL shader shenanigans.

During all of this we'll cover some of the implementation details of the different packages, and how to start using them. I will also try to demonstrate how to use the `jsaddle` and `ghcjs-dom` packages to access JavaScript functions without needing any explicit FFI calls.

Goals

• Introduce people to two new Haskell libraries for creating visual treats in a modern browser.
• Demonstrate that programming these applications using Haskell is possible without having to go wild with a foreign function interface or arcane build process.
• Inspire people to try out building games, art, or simply beautiful things using FRP and Haskell. - Introduce more people to `reflex` and FRP.

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 WebAssembly MVP is now available in almost all browsers (except IE) providing a fast virtual machine right in your browser. Opening up the web for strong & statically typed functional programming languages*. This presentation will show a simple and elegant code generator that generates WebAssembly from an abstract syntax tree (AST) for a ML-like language. Furthermore the basic algorithm is so straightforward you'll be filing PRs against your favourite compiler next week!*

*: Almost: The WebAssembly MVP leaves a couple of really awesome features unimplemented, but it won't be long and these problems will be solved too. We just want to make sure you're ready.

The presentation will also discuss other architectures including x86_64 and LLVM.

People advocate prototyping filters in Matlab (and more recently in Python). I've benefited a great deal from using Haskell instead. Haskell brings type- sanity and encourages designs where the resulting filters are generic and composable. By the time a prototype is reimplemented in C++, most of the hard work around design is complete. The code left behind is terse and closely represents the underlying Math. Translating such lean code into prosaic C++ is not too hard, and reduces the chances of getting mired in language details. This approach could add to the toolbox of people who straddle the C++ and Haskell worlds.

Think about things as simple as network sockets or database connections, these are implicitly stateful. It only makes sense to perform a read on a socket that is open and has data available. Likewise you can't send an SQL statement to a closed database connection.

State machines also occur naturally in various protocols like distributed consenseus algorithms like PAXOS or RAFT.

Despite the ubiquity of state machines they aren't typically checked by compilers even in strongly typed languages like Haskell or OCaml.

In this talk we will look at approaches to using dependent typing to provide extra safety in encoding state machines, using both Haskell and Idris. And look at how we can introduce dependent types into our code without making the types incomprehensible and difficult to work with.

The talk is aimed at intermediate level programmers with a familarity with a typed programming langauge like Haskell, Idris or OCaml, and aims to provide a motivation for using dependent types in a practical setting. When new techniques and ideas occur in academia it is important that they are investigated and evaluated in a pragmatic way. Only introducing new things if they provide real and measurable benefits. I would like people to get an appreciation of what dependent types could do and how to critially think about new features in a language.

In this talk, we'll look more closely at laws themselves. 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.

We will look at examples of the utility of associativity and identity in working with Monoids. Concretely, appending a collection of lists going from left to right is O(n^2), but associativity gives us the power to append them all in O(n) - while knowing we'll get the same answer. More abstractly, we'll see that without the laws, the number of useful functions we can write in terms of Monoid's interface is severely diminished. Similar arguments, both in the abstract and the concrete, will be made for the Functor laws of composition and identity, and the Monad laws. The common theme is that laws let us get the most out of our abstractions. This is further highlighted by examining Data.Default - a dreaded lawless type class.

Finally, we will make recommendations about how to verify whether the laws pass when one makes an instance of an abstraction, using the testing libraries QuickCheck and checkers.

Goals

An attendee should learn why giving laws to our abstractions helps us work with and understand them. Attendees should leave the talk better equipped to exploit the advantages of these laws and with knowledge of how to test whether they hold.

When we began experimenting with Elm in production nearly two years ago, we immediately encountered a number of surprises (confident refactoring, helpful compiler errors) and pain points (CSS integration, DOM access). Nevertheless, the positive impact on the team's productivity was undeniable.

As our single-team experiment has grown across teams to the point where we are now writing as much Elm as we are JavaScript, the surprises and pain points have changed. We've solved some of our initial challenges and open-sourced those solutions (CSS integration), while new surprises like Elm's impact on hiring and compiler performance on large projects have appeared.

`hedgehog`, as its project page tells us, will eat all your bugs. More specifically, it is a Haskell library that provides excellent support for both of these styles of testing. Although `hedgehog` is a Haskell library, its usefulness is by no means limited to testing Haskell code. In fact, coupled with some other libraries and tools, it can be used to great effect when testing any software. Even something like... WordPress.

WordPress, for anyone who hasn't investigated setting up a blog in the last 15 years, is a blogging platform implemented using PHP and MySQL. WordPress is not written in Haskell or anything resembling a functional programming language, its REST API is under specified, and it makes extensive use of JSON objects with fields that may or may not appear depending on the context in which the object is used. At first this might not appear to be a good candidate for testing with a typed, functional language. Appearances can be deceiving. Haskell and its ecosystem are well equipped to tackle this problem, bringing with them all of their usual benefits. You don't have to take my word for it either -- I've written the code.

In this talk I will provide a tour of the tools and techniques I've employed to test WordPress. The main players are:

• `hedgehog` to perform state machine testing, including concurrency tests.
• `servant` to generate client request functions given a specification of the REST API.
• `dependent-map` to model the dynamic JSON objects.

The final ingredient in this functional, testing cocktail is Nix. I will briefly show how NixOps and Nixpkgs provide a means to specify a test environment in a succinct and declarative manner, and then deploy that specification to a virtual machine for testing.

Attendees should leave the talk with a high-level understanding of state machine testing and the tools and techniques that can be employed to test complex APIs not written in Haskell. All source code will be made publicly available under an open source licence after the talk.

One of the examples pertains to scalajs-react, a library for type-safe, frontend FP in Scala.JS, which builds on top of React, a pure JS library. When creating scalajs-react, I faced a difficult problem: React itself has a feature that it implements in such a way that confidence in its correctness is difficult and flaky. How would I implement this in Scala and maintain my goal that compilation is proof of correctness (as reasonably as one can in Scala anyway). I ultimately devised what I think is a novel, unique solution, and it has worked tremendously well in practice. scalajs-react now implements React's feature better than React itself will ever be able to without access to more advanced language features. It also leads to the insight that it can be a profoundly valuable technique to solve a problem for universal and existential quantification separately.

In this talk, we will learn about Comonads (the opposite of Monads). How do they work? What does it mean to be the opposite of a Monad? How can we use them?

We use the Zipper data structure to provide an intuition for how Comonads work. Then extend the Zipper to a Grid, to implement Conway's game of life.

You will walk away from this talk with an intuitive understanding of Comonads. The concept of duality, and where you can use Comonads.

In this presentation, I will give a brief introduction to Alda and its purpose. I will provide a lightning-fast tutorial, demonstrating the basic features of the language, accompanied by live audio from Alda's "Read-Evaluate-Play-Loop" (REPL). As I type each snippet of Alda code into the REPL, the audience will hear the result. I will then show and play examples of Alda scores, demonstrating some of the artistic possibilities that can be achieved when writing music as Alda code. This will include an explanation of how one can build a musical score out of modular components, an idea which is at the heart of functional programming, and one which I believe can also be applied to composing a musical score.

• Be instantly accessible via the web, with no setup required
• Have no lecture material, being composed entirely of exercises
• Progressively teach concepts without requiring jumping around
• Be completely broken! Every exercise will crash, requiring debugging

Skeptical? Come along and find out if this was a terrible idea!

Note: This is an introductory workshop. Please bring a laptop with a modern web-browser.

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`.

This workshop will comprise of a short talk that introduces the main parts of a compiler, followed by an at-your-own-pace tour through building a little one of your own. We'll start with a simple language that compiles to JavaScript.

We'll be stepping through:

• Tokenising (taking a string and turning it into a bunch of symbols),
• Token Parsing (taking these symbols and turning it into a representation of a program), and
• Code Generating (taking that representation and turning it into, in this case, JavaScript).

This workshop is for people who are already somewhat familiar with JavaScript (just the language itself, not any particular library or framework).

To get going you only need this repository, a Terminal / Console, Node.js 8+, and a text editor of your choice.

Prerequisites

• Node.js 8+ (if you don't have it, then visit the Node.js download page, or use your package manager to install it, eg. Homebrew on macOS).
• The workshop repository at https://github.com/damncabbage/js-compiler-workshop. (Copies will be provided at the workshop as well.)

So far I've run the Task exercises internally at REA and 1 hour was sufficient for that. I suspect another hour will cover the Observable exercises (which I'm still working on). https://github.com/lukestephenson/monix-adventures

Prerequisites