Melbourne 2016 Day One - Speakers and Presentations

Welcome to Compose :: Melbourne!

Graphics and animations are not only fun, they are also an effective learning tool. For example, fractal tree structures nicely illustrate recursion, and animations are often more motivating and engaging than examples and exercises spewing out text. In this talk, I will demonstrate graphics and animations in Haskell playgrounds — aka the REPL on steroids. The immediate feedback of playgrounds facilitates an explorative style of programming that is especially attractive for graphics programming.

Graphics, animation, and games programming in Haskell faces a dilemma. We can either use existing frameworks with their highly imperative APIs or we waste a lot of energy trying to re-engineer those rather complex systems from scratch. Or, maybe, we can escape the dilemma. Instead of a Haskell program directly manipulating the mutable object-graph of existing frameworks, we provide an API for purely functional transformations of a Haskell data structure, together with an adaptation layer that transcribes those transformations into edits of the mutable object-graph. I will illustrate this approach by describing the architecture of a Haskell binding to the animation system of Apple’s SpriteKit framework.

One of the first lessons we are taught in FP is that all functions should be “referentially transparent”. Amongst other implications, this means a function can’t throw an exception. Great in theory, but often, in the real world, we know we can get errors. A file read may fail, data may be missing from our repository, a network error may occur in a remote call, so how do we model this? For those of us that are writing robust, stable production code, surely this makes our life more difficult?

Based on our production Scala code, this talk takes an in depth, practical look beyond how we handle a single function that can return an error, to how we can compose these simple functions into larger functions and whole systems, while avoiding an explosion of complexity. On the way we will visit a number of generic functions available to us through monad and applicative types, and gain an understanding of the power and increased productivity these tools give us. The talk will be a category theory free zone, with examples using Scala and the scalaz library, aiming to show the value of monads in a practical scenario.

Plasma is a very new, pure, strongly-typed programming language that strikes a compromise between imperative and declarative programming. We aim to create a language with the safety guarantees of a typed purely functional language, but that is easier to learn and use. Plasma will feature many conveniences found in both paradigms including: loops, arrays, first class functions and coroutines. Our second goal is to create a language and tools that makes parallel and concurrent programming easy and safe. Plasma will provide useful language features and many abstractions for concurrent and parallel programming.

We've been using Datomic in production for nine months now, and this talk is an experience report. Datomic is an immutable database with a logic-programming-based query language. Lots of Clojurists have played with it, but there aren't many in Australia who've dealt with it day-to-day serving real customers.

It's been interesting, and fun, but there have been headaches and pitfalls, and things I wish I'd done differently from the outset of the project.

Things I can cover:

• How we combine it with DataScript in the browser to share transactional logic and validations
• What deployment looks like
• How we make use of its unusual time model to do things that would otherwise require denormalisation
• Tradeoffs we made initially (and have discovered since) when comparing it to traditional relational DBs
• How its declarative “pull syntax” makes it easy to hydrate React components
• Mistakes we made with the DB schema, and how we fixed those (including data migrations)

Alistair has given talks before at MelbJS, MelbJVM, MFUG, clj-melb, Manilla JS and Decompress on a range of topics.

Cloud Haskell is a collection of libraries that have brought Erlang style networking patterns to the Haskell language. The libraries bring together the best of Haskell’s strong typing, with an opinionated approach to building distributed applications. I will provide an experience report on how we have used Cloud Haskell, and Haskell in general, to build a continuous integration platform to support the rest of our data science work. The project has been successful in our organisation, and is starting to be used by other partner organisations. I believe that Haskell has helped development by making it easy to refactor, while also being extremely reliable in production. Cloud Haskell has allowed us to scale up to hundreds of compute nodes, and tens of thousands of computations in parallel, without changing any code.

Haskell is now an essential tool at Dragonfly Data Science. I will also discuss our experience with building up Haskell skills across our team, and across a range of projects.

Dragonfly is a data science team that combines research science and software development experience. We are committed to realising the benefits of using reproducible methods for all our work, for ourselves, our clients, and the general community.

A major advantage of functional programming languages is that they allow for analysis and transformation based on 'equational reasoning'; an idea that has deep roots in computing history. In his seminal Turing Award lecture from 1977, John Backus advocated the functional style over traditional 'von Neumann' languages, citing algebraic program manipulation as a major selling point. Similar ideas were further expanded in the Bird-Meertens formalism, fondly known as 'squiggol', yielding an elegant calculus for iterative program construction. The use of simple equational laws is very attractive, even if the presence of 'undefined' values sometimes violate such laws: Danielsson et al. have shown that, in a precise sense, equational reasoning is still justified. In their words, 'fast and loose reasoning is morally correct'.

There are, however, circumstances where programmer intent needs to be taken into account. Programmers routinely make tacit assumptions about what may or may not happen when a program runs, making liberal use of deliberate under-specification. For example, when coding a merge function we typically assume the arguments are sorted lists. The under-specification or "don't care" status of a computation is best seen as a dual to undefinedness. It can manifest itself during debugging, for example, when a programmer is required to judge the correctness of an expression that violates a precondition (such as merge applied to unsorted lists), and therefore has no particular intended meaning.

We argue that, in the context of a 'programmer-intended semantics' which is usually partial, certain kinds of reasoning with equality are inappropriate and that equality should instead be replaced by a partial ordering of values taking "don't care" into account. In our presentation we aim to explain what goes wrong with naive equational reasoning in the presence of under-specification, how it can be adapted to avoid these pitfalls, and the influence on how we think about our code and design programming environments, including tools for testing, debugging and verification.

This is with joint work with Harald Sondergaard and Bernard Pope.

This talk introduces the Eff monad via Eff-cats Scala library, and gives a sense of how use it to solve practical programming problems.

The Eff-cats library is an implementation of the Freer monad concept in Scala, developed by Eric Torreborre. It is inspired by Oleg Kiselyov's Haskell paper 'Freer Monads, More Extensible Effects' . Like Monad Transformer stacks and the Free monad, it provides an organising principle for the construction of pure functional programs. It has a number of desirable qualities:

• Purity: the construction of the program is decoupled from its interpretation
• Type-safety: Effects such as error handling or asychronicity are visible in the type signatures
• Flexible effect stacks: the final effect stack members can be varied without unduly affecting local code
• Performance: scales gracefully, as the program is stored as a Vector of continuations
• Flexible evaluation: effects interpretation can be reordered without rewriting the program

This talk focuses on what code written using the Eff monad looks and feels like. It covers several common Eff 'effects' including

• Using Reader effects for dependency injection
• Using Either effects for error handling
• State effects for stateful computation

It will also demonstrate some challenges that arise when using Eff and how to tackle them:

• Adding new effects to an existing program
• Mixing Eff-based and non-Eff modules together

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.

In web development, a great deal of effort is spent on consistency. The frontend, backend and database must all agree on a data-model, and if they don't, the system crashes spectacularly.

The default solutions are either to invest heavily in hand-written integration tests, or use JavaScript everywhere. Neither of these are ideal. However there is a compelling alternative - use the same types everywhere.

By reusing strong, static types across tiers, we can make guarantees about the consistency of the entire system, and dramatically lower the cost of change.

We present one approach that uses Haskell data types to drive a both a PostgreSQL database schema and a frontend system written in Elm. With one set of types to rule them all, whole system consistency is automatic and reliable, and the cost of changing types - and hence evolving the whole system's data model - is dramatically reduced.

Manipulating immutable data structures can involve laborious pattern-matching and copying. Functional optics such as isos, lenses, prisms, traversals and folds help us compose data manipulations. Manipulations can include getting, setting or modifying.

This presentation will show examples of optics used in production business applications. It will start with PureScript's 'pure profunctor lenses' library, then move on to examples in the Haskell, Scala and Java optics libraries, acknowledging the increasing compromises of each.

Fans of strongly statically typed languages will tout the benefits of their type system such as: mistakes are detected earlier, types serve as a form of machine-checked documentation, increased run-time efficiency, and so on. But a point that is sometimes missed is that types make refactoring your code much easier. This is important since maintaining a program is a huge part of its life cycle!

In this talk I will refactor two small programs live. One will be written in Haskell, which has a strong static type system, and the other in Ruby, which has a dynamic type system and somewhat 'loose'. The programs will be written to be as close in functionality and structure as possible. I will then propose a change to the API of the programs for which a refactor will be required. I will then demonstrate the markedly different experience that a somewhat error prone developer will have when refactoring the two programs.

In consulting, freelancing, or even in-house work, we may not always be able to choose the language we work in. Magdalena and Aaron both spent a year working in Clojure before moving on to other projects in a variety of Object-Oriented languages. By applying the principles of functional programming in these other contexts, we were able to write cleaner, more efficient, more testable code. We will discuss the ways in which our experience in FP has informed our design choices in other paradigms.