Programme


Day 1 - Talks

Monday 27 August 2018 RMIT - Building 80
8am
Registration
9am Ken Scambler Introduction by the Committee
9:30am Julie Moronuki Keynote - The Unreasonable Effectiveness of Metaphor
10:15am
Break
10:30am Sean Chalmers Reflexive Art
11am Jo Cranford Drinking the Elixir
11:30am Dr. Paul Bone AST to WebAssembly: writing a code generator
12pm
Lunch
1pm Rohit Grover Prototype Driven Development using Haskell
1:30pm Tim McGilchrist Dependently Typed State Machines
2pm George Wilson Laws!
2:30pm
Break
2:45pm Kevin Yank Elm at Scale: Surprises and Pain Points
3:15pm Andrew McCluskey Appetite for dysfunction
3:45pm David Barri Quantifiers in Programming
4:15pm
Break
4:30pm Elias Jordan Life Is A Comonad
5:00pm Dave Yarwood A music composition language with a functional backbone
5:30pm Lyndon Maydwell Closing comment
 

Day 2 - Unconference

Tuesday 28 August 2018 RMIT - Building 80
9am
Registration
10am Rob Howard WORKSHOP - Building a Small Compiler in JavaScript
11am Lyndon Maydwell WORKSHOP - CRASHKELL
1pm David Laing WORKSHOP - Front-end development with Reflex
2pm Luke Stephenson WORKSHOP - Monix adventures


Day 1 - Talks

Monday 27 August 2018

8am

Registration

Ken Scambler
9am

Introduction by the Committee

Julie Moronuki
9:30am

Keynote - The Unreasonable Effectiveness of Metaphor

Metaphor is a figure of speech that describes one thing in terms of another, ignoring literal differences in favor of some similarity the author wants readers to notice. Most people come away from their English or literature courses with the impression that this is all metaphor is, a poetic device that might be pretty but is always unnecessary and may even obscure the real world or obstruct technical discussions.

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.

About Julie Moronuki

Julie Moronuki learned Haskell while writing Haskell Programming from First Principles. She has degrees in philosophy and linguistics and formerly worked as a language teacher and librarian. Her interests include the intersections of linguistics, logic, and programming, as well as improving functional programming instruction and outreach. Currently she is writing a second book, The Joy of Haskell, and is a co-founder of Type Classes (typeclasses.com). In her spare time she homeschools her two children and makes too much jam.

10:15am

Break

Sean Chalmers
10:30am

Reflexive Art

Web development need not only be sign-up forms and shopping carts. There's games to build, data to visualise, and a myriad of thoughts to be brought to life. This talk is about two Haskell packages that can help.

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

Drawing upon inspiration from the Generative Art talk by Xavier Ho at LambdaJam 2018. I will demonstrate two new libraries from QFPL for interfacing with SVG (`reflex-dom-svg`) and HTML5 Canvas (`reflex-dom-canvas`). I will also touch on the utility provided by `jsaddle` and `ghcjs-dom` packages.

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.

About Sean Chalmers

Sean started out developing for the Drupal platform, before studying overseas and releasing a paper on the ‘State of the art of Big Data’, which is no longer state of the art. During this time he discovered FP through Lisp, Erlang, and eventually Haskell.

After briefly contracting with PHP, he was eventually able to use his FP powers for good, developing everything from simple JSON to PostgreSQL pipelines, CRM components, and robust data munchers. Sean is interested in game development, and improving the state of FP documentation and education.

Jo Cranford
11am

Drinking the Elixir

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.

About Jo Cranford

Jo is a technical leader with a passion for enabling teams to work better and grow together. Her interest in workplace culture led her to Culture Amp, where she is part of a global movement to make the world a better place to work while putting her technical background to good use.

When she's not working, she's a maker of things. Jo spends her free time creating artwork and papercraft projects, and her cupboards are bursting with paper scraps, paintbrushes and sparkly trimmings.

Dr. Paul Bone
11:30am

AST to WebAssembly: writing a code generator

Ever wonder how your compiler translates your program into machine code but worried that this was some eldritch knowledge, lurking in the depths of compilers where undergraduates fear to tread? Well it's not, and although it's a deep topic, the basics are fairly basic.

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.

About Dr. Paul Bone

Dr Paul Bone is a talented software engineer and computer scientist. His interests include programming language implementation and performance, including parallelism and concurrency.

By day Paul works for Mozilla where he is a humble garbage collector, sweeping up unused objects from Firefox's JavaScript heap. Err.. Senior Software Engineer, Paul works on the garbage collector for Firefox's JavaScript engine.

At night Paul transforms into his alter-ego and works on the new Plasma programming language, which aims to bring the worlds of functional and imperative programming together! With the powers of these worlds unified we will usher in a new age of large scale, reliable, high-performance parallel and concurrent software.

12pm

Lunch

Rohit Grover
1pm

Prototype Driven Development using Haskell

This talk presents a simulation-driven approach for the development of data estimation filters (Kalman filters) using Haskell. In my professional work around radar target tracking, I use Haskell to develop, visualize, test, and iterate over estimation filters. I tweak them to my heart's content, often trying many Mathematical models, before translating mature filters into C++ as a final step.

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.

About Rohit Grover

Rohit has been a systems programmer for the past 20 years, using C/C++ for products ranging from multiprocessor kernels to bare metal embedded systems. At his current job, he is responsible for developing filtering algorithms for radar target tracking. Most of his professional work requires writing modern C++, but increasingly he finds himself reaching out to Haskell to write correct code faster.

Tim McGilchrist
1:30pm

Dependently Typed State Machines

State machines naturally occur in software systems we write, with many components reling on state as a core principle. We use state machines to describe things like TCP/IP networking, distributed algorithms and everyones favourite regular expressions.

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.

About Tim McGilchrist

Tim McGilchrist began his career as a mere midshipman, with some experiences in the exotic lands of Erlang, Lisp and OCaml. He developed a liking for the rough sailor life, strong types and a tot of rum. He quickily progressed to more daring exploits in distributed systems and contrarianism which gained him the promotion to lieutenant. After some gruelling service where he was blockaded at Brest using un-mentionable non-FP languages, he was offered a promotion to Master and Commander of Big Data at Ambiata. Once there, he met a number of gizzled Haskell verterans and went to work on special operations in infrastrure, machine learning and big data. After the Ambiata crew dispanded he continued operations in machine learning and big data using OCaml and Haskell in the area of high finance and brigandry.

He brings before you the tales of an adventurer in the wild lands of Real Life Functional Programming.

George Wilson
2pm

Laws!

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

About George Wilson

George Wilson is an enthusiastic functional programmer from Brisbane, Australia. He works on open source Haskell projects at the Queensland Functional Programming Lab inside Data61. George is a member of the Haskell.org committee, and a Hackage Trustee.

2:30pm

Break

Kevin Yank
2:45pm

Elm at Scale: Surprises and Pain Points

The ups and downs of Culture Amp’s rollout of Elm – a pure functional, strongly typed language for building web front ends – to its commercial, production application, and a team of engineers familiar with JavaScript and React.

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.

About Kevin Yank

Culture Amp’s Director of Front End Engineering, Kevin previously spent a decade teaching a generation of developers about web standards at SitePoint, where he also helped to launch success stories like 99designs and Flippa. More recently, he quizzed web developers on HTML, CSS and JavaScript by leading the team behind Sit the Test, and has spoken at tech conferences around the world. On weekends he performs improvised theatre with Impro Melbourne, which is a lot more like building websites than you might expect.

Andrew McCluskey
3:15pm

Appetite for dysfunction

Property based testing is an unreasonably effective technique for finding bugs and providing minimal test cases to reproduce those bugs. It achieves this by randomly generating inputs, providing those inputs to the software under test, and ensuring that the outputs uphold some desirable properties. Property based state machine testing extends this technique to more easily test stateful software, using state machines to model the application while ensuring that the model and application continue to agree.

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

About Andrew McCluskey

I'm a functional programming engineer in the Queensland Functional Programming Lab at Data61. Earlier in my career I worked across a range of domains using conventional imperative programming languages, growing more and more frustrated with the difficulties of reasoning in a stateful and often untyped world. At some point I encountered Clojure and the ideas of immutability and referential transparency, which quickly changed the way I thought about solving problems. From there I discovered the benefits of a good type system and have been learning and using Haskell to solve problems whenever possible.

David Barri
3:45pm

Quantifiers in Programming

In this talk I'll describe quantifiers and how they manifest in programming (at both type and term levels). I'll then go on to show two very different real-world problems that were solved to profound benefit, using quantification.

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.

About David Barri

David loves to create!

His primary outlet and passion is programming, with music being second. In fact, David has been obsessively coding and creating since the age of 8 and is still just as excited about it. A common theme throughout all his creation of software, is the striving for, and emphasis on quality. Two of the most important tools towards achieving and maintaining high quality software are a strong, expressive, static type-system; and the functional programming universe (as in: beyond just the paradigm).

Over the past 6 years David has been writing pure FP Scala almost exclusively through a mixture of bootstrapping a requirement management SaaS startup, creating and maintaining numerous open-source Scala and Scala.JS FP libraries, consulting, and when time (and family) permit, sharing learnings and experiences to help others up the learning curve.

He moved to Melbourne just under a year ago. Feel free to say hi! You can also find him on twitter at @japgolly .

4:15pm

Break

Elias Jordan
4:30pm

Life Is A Comonad

Today is opposite day! Lets explore duality and co-things.

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.

About Elias Jordan

I am currently a lead developer at IBM, leading the infrastructure team of the cloud product Watson Content Hub.

My first programming language was Haskell, but I was diverted into enterprise java for quite some time. I have always maintained my passion for functional programming and in the last few years have convinced my workplace to embrace scala and functional programming techniques. I believe strong static typing, and purity are the only way to maintain your sanity while maintaining complex distributed systems.

Dave Yarwood
5:00pm

A music composition language with a functional backbone

Alda is a music programming language that offers a way to describe a musical composition in the form of a text document. The language has an easy-to-use syntax that is well-suited for both musicians with little-to-no programming knowledge and programmers with little-to-no music theory knowledge. Alda is inspired by existing music/audio programming languages such as MML, LilyPond and ChucK, but aspires to be a general-purpose music programming language that gives composers the power to create music in many different ways, all while maintaining simplicity and ease of use.

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.

About Dave Yarwood

Dave Yarwood is a composer, musician, and software engineer at Adzerk, where he uses Clojure and ClojureScript to build UIs, APIs, and backend services. In his free time, he maintains Alda, a programming language for music composition. Dave holds a Bachelor of Music degree from the University of North Carolina at Chapel Hill.

Lyndon Maydwell
5:30pm

Closing comment


Day 2 - Unconference

Tuesday 28 August 2018

9am

Registration

Rob Howard
10am

WORKSHOP - Building a Small Compiler in JavaScript

"Compilers" are usually-mysterious things that a lot of us actually use and rely on from day to day, eg. the JavaScript V8 compiler, the TypeScript compiler, or the Clang+LLVM compilers. Digging into how these work can be satisfying (like sleuthing a good puzzle); but some of the ways we implement them can appear in other forms, such as when validating user input, transforming big structures, or when separating side-effects from business logic.

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

About Rob Howard

Hi! I'm Rob, and I'm a web developer who currently switches between Elixir, Ruby and TypeScript at work up in sunny Sydney. Having so far made a career from learning and mixing the nice parts from different programming languages, I love nothing better than to help programming communities to learn more from each other, and become more welcoming for newcomers.

Lyndon Maydwell
11am

WORKSHOP - CRASHKELL

The feedback from last-year's Haskell workshop was clear: "Less Talking, More Typing!". In response to this, I have reworked the content to...

  • 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!

About Lyndon Maydwell

Lyndon has run Haskell workshops for the past 5 years.

David Laing
1pm

WORKSHOP - Front-end development with Reflex

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

About David Laing

Dave is a programmer working at the Queensland Functional Programming Lab.

He is mostly interested in programming language theory, functional reactive programming, Nix, session types, and various other bits and pieces of mathematics and theory associated with functional programming.

He is also passionate about spreading all of this knowledge, mostly by giving talks and writing blog posts and other training material, but also via talking to people at conferences, in pubs, and during elevator rides.

Luke Stephenson
2pm

WORKSHOP - Monix adventures

An introduction to Monix Task and Observable. Both are introduced through a series of problems which need to be solved using Monix APIs. Tests are provided so participants can see progress and know the solution works.

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

About Luke Stephenson

Lead Developer at REA. 3 years commercial Scala experience.

On the Melbourne Scala User Group committee.


Register for C◦mp◦se :: Conference 2018 tickets at Eventbrite