Can reactive designs be implemented in any programming language? Or, are some languages and programming paradigms better for building reactive systems? How do traditional design approaches, like Object-Oriented Design (OOD) and Domain-Driven Design (DDD), apply to reactive applications. The Reactive Manifesto strikes a balance between specifying the essential features for reactive systems and allowing implementation variations appropriate for each language and execution environment. We’ll compare and contrast different techniques, like Reactive Streams, callbacks, Actors, Futures, and Functional Reactive Programming (FRP), and we’ll see examples of how they are realized in various languages and toolkits. We’ll understand their relative strengths and weaknesses, their similarities and differences, from which we’ll draw lessons for building reactive applications more effectively.

specs2 has been around for 4 years now and while it tried to take the “functional route” (with immutability at least), it is actually largely using uncontrolled effects.

This talk will present a diagnosis of everything that is not “functional” in specs2, and will describe implemented or proposed solutions to remediate to this. Here’s a list of some problems:

• system properties are read directly
• the file system is accessed to get the state of previous runs and written to after execution
• some configuration is global (execution context for threads)
• text is freely emitted to the console via printlns
• an attempt at processing lazily the execution miserably failed (via Reducers)
• the code base is not easily extensible to create new reporters

The solutions (still being implemented/experimented) include:

• using a ReaderT / ErrorT / WriterT / IO stack to control effects. This actually opens very interesting possibilities in terms of flexibility for writing your specification! Question: how tedious is that to use in practice?
• using scalaz-stream to process results as they happen, even when running concurrently. This should remove some poorly performing code and simplify the code base. Question: does it work with specs2 execution model where it is possible to run only some sections of the specification concurrently, where a failed execution can stop the rest of the processing,…?
• using functions extensively instead of traits to compose functionality (who knew?). Traits will only be used to compose implicits for DSLs. Question: why not take the Cake Pattern route?

In conclusion we will talk about strategies for effectively migrating a non-functional code base to a functional one. What was learnt during this experiment?

Established generic sorting is based on comparison and is known to have a lower bound of O(n log n). In a recent paper1 Fritz Henglein sets out an approach based on discrimination which has a lower bound of O(n), a fundamental improvement to the state-of-the-art. In this talk Haskell and Scala implementations of generic linear time sorting, based on this paper, will be presented. Performance measurement methodology and the initial, encouraging results will be discussed.

Academic research can often be intimidating, and bridging the gap between paper and implementation can seem like a big task. In this talk the speaker will share their perspective on this process.

The talk seeks to demonstrate that composition can yield fundamental insights, that research is more accessible than people may think, and to show interesting implementation details of the algorithm by comparing and contrasting Scala and Haskell.

Pre-Requisites: Familiarity with Haskell and/or Scala syntax, and garden variety sorting algorithms.

References: Various papers on the topic are widely available, of which the two most relevant are, 1 Henglein, Fritz. “Generic top-down discrimination for sorting and partitioning in linear time.” Journal of Functional Programming 22.03 (2012): 300-374. 2 Henglein, Fritz, and Ralf Hinze. “Sorting and Searching by Distribution: From Generic Discrimination to Generic Tries.” Programming Languages and Systems: 11th Asian Symposium, APLAS 2013, Melbourne, VIC, Australia, December 9-11, 2013. Proceedings. Springer International Publishing, 2013.

Template Haskell is usually associated with reducing boilerplate or code generation. However, it is also a powerful tool for problem solving with a type system. We discuss using Template Haskell to construct proofs, infer function implementations and create interesting data structures at compile time.

In order to expand the functional programming community we must be able to effectively educate people about our craft; this presentation will offer some ideas for doing so. Possible teaching languages and approaches will be discussed generally before two experience reports are presented from FP workshops run this year: the NICTA Lambda Ladies Brisbane event and the Functional Programming in the Cloud session at Codemania New Zealand. The talk will touch on the use of cloud technologies for education and include a demonstration of creating a simple Haskell web application in the cloud.

Code smells in other languages like Java are well understood and documented but what about Clojure? Does the language make all these problems and smells go away? For many of us starting to write our first production Lisp, the territory is unfamiliar and smells are not immediately apparent. In this talk, I explain why we should start to think about Clojure smells and describe some of the patterns that might make the list. (Warning: may contain depictions of unsightly code and offensive parentheses.)

The goal of this talk is to start to start the discussion off about what kinds of smells and anti-patterns could show up in Clojure code, what to do about them and what they may tell you about underlying issues. I don’t intend to create a full catalogue, more to make a start and see what other anti-patterns other people have noticed.

References: Martin Fowler on Code Smells: https://martinfowler.com/bliki/CodeSmell.html (also the book chapter authored with Kent Beck in Refactoring https://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672)

Datomic is an interesting new database that attempts to bring much of the benefits of functional programming to the database arena, with a focus on immutability. Datomic separates out the traditional tasks of a database allowing rich queries to be performed at the application level. In this talk attendees will learn about how this ability, along with the functional aspects, make Datomic an attractive option for storing spatial data (coordinates, polygons, etc.). Efficiently querying spatial data requires some form of spatial indexing. I will show how I leveraged the ability for Datomic to describe arbitrary data structures and wrote a spatial indexer for Datomic in Datomic (and Clojure) it’s self. I will provide a short walk through of the implementation, describing the algorithms and techniques used, including R-Trees and Hilbert Curves.

Lenses are bidirectional transformations between pairs of connected structures. Asymmetric lenses, where one of those two connected structures is taken to be primary, have been extensively studied. Lenses were first proposed to solve the view-update problem of tree-like data structures by Foster et. al and have also been applied to the construction of a relational database query language. Other work has altered the primitive structure of lenses to achieve different results.

The lens data structure has recently gained increasing attention as a technique for generic programming on algebraic data types. Lenses have been written about using various programming languages including Haskell and Scala and using many different representations.

In this talk, we will look at the lens data structure and its representations, then discuss the trade-offs and motivations for revisions. Some of the theory is discussed, before we look at the most recent incarnation of lenses by Edward Kmett, which take the Twan van Laarhoven representation, apply it to practice and also develops the theory further resulting in to the Control.Lens module.

Control.Lens resolves many of the practical limitations of lenses that had been encountered by earlier implementors by exploiting some insights that had not previously been published.

E. A. Kmett, Lenses, Folds and Traversals available at https://www.youtube.com/watch?v=cefnmjtAolY

Twan van Laarhoven; Institute for Computing and Information Sciences – Intelligent Systems, Foundations Seminar; May 2011

Control.Lens available at https://hackage.haskell.org/package/lens

Russell O’Connor; Polymorphic Update with van Laarhoven Lenses available at https://r6.ca/blog/20120623T104901Z.html

Russell O’Connor; Functor is to Lens as Applicative is to Biplate: Introducing Multiplate; 2011

Foster, J. Nathan and Greenwald, Michael B. and Moore, Jonathan T. and Pierce, Benjamin C. and Schmitt, Alan; Combinators for bidirectional tree transformations: A linguistic approach to the view-update problem; May 2007.

Bohannon, A. and Pierce, B.C. and Vaughan, J.A.; Relational lenses: a language for updatable views; 2006

Foster, J.N. and Pilkiewicz, A. and Pierce, B.C.; Quotient lenses; 2008

Jones, M.; Functional programming with overloading and higher-order polymorphism; 1995

This talk will build on the work of Philip Wadler (1) and Danielsson et al (2) to demonstrate using types to document source code behaviour and to assist in reasoning about code. Specifically, the concept of parametricity is used to tacitly eliminate possibilities in code behaviour leaving only a few, sometimes even one, remaining potential candidates.

1. Theorems for free!, Wadler, Philip, Proceedings of the fourth international conference on Functional programming languages and computer architecture,
   pp 347 – 359, 1989, ACM
2. Fast and loose reasoning is morally correct, Danielsson, Nils Anders and Hughes, John and Jansson, Patrik and Gibbons, Jeremy, ACM SIGPLAN Notices, vol 41, num 1, pp 206 – 217, 2006, ACM

Increasingly systems are required to include ideas from distributed systems to achieve their goals of availability, performance and maintenance. As people dive into the distributed systems literature, they often have problems with finding practical information about building distributed systems. With this in mind, RAFT is an algorithm for providing distributed consensus that focuses on providing an understandable and more easily implemented solution for people building distributed systems.

Erlang/OTP is programming languages that focuses on concurrency, fault tolerance and building massively scalable soft real-time systems. It’s only natural we’d want to build a distributed algorithm with such a language.

In this talk we’ll look at:

• the need for distributed consensus,
• understand how RAFT works, and
• show how RAFT can be implemented in Erlang/OTP

Several libraries that enable action game programming in Haskell have emerged, allowing us to play with game ideas in the strictest of functional programming environments. Come along for a brief introduction to game programming using Netwire, a library for functional reactive programming in Haskell. You will learn, perhaps surprisingly, how well functional programming fits with game programming models. In deconstructing the Wire type, we’ll learn useful methods for thinking about complicated parametric data types.

Our case studies are Flying Sheep Battles, a 2-player physics-based game written in Haskell over a weekend, and the presentation itself, which is also a Netwire application.

With the Haskell Streaming Library War waging around us, we will choose a side, dive into Pipes, and build a “working programmers” understanding of what Pipes is and how we can use it in our day-to-day programming.

Pipes is at its core a very general library, and can be used to solve a variety of problems far beyond streaming. It’s a useful replacement for a number of programming patterns that most programmers encounter day to day, including logging, working with cooperative programs (such as callbacks), and of course, parsing.

This talk will explain the building block functions and types used to construct and evaluate Pipes, using a number of examples drawn from both the pipes library itself, and other sources. We will learn how to reason and compose pipes, a key requirement for any functional program.

By the end, we shall see that pipes is a useful addition to the Haskell toolchest, that has general application to a range of problems.

Functional programming provides a fundamental basis for reasoning about our programs and building out principled abstractions. However, it is not enough on its own and we also rely on other programming tools to aid in constructing programs correctly and efficiently. An advanced example of such a tool is dependent types; that is, types that depend on values. Dependent types can be used to provide strong guarantees about a program’s behaviour that are difficult or impossible to express with traditional type-systems.

Dependent types are gaining traction in mainstream FP languages such as Haskell (via language extensions) and Scala (via path-dependent sub-typing), but disappointingly, they are still less accessible to everyday programming than they can and should be. To help address this problem, Idris is a new programming language built from the ground up with the explicit goal of having better support for dependent types (as well as a number of other useful tools such as totality checking and tactic based theorem proving).

This talk will step through an end-to-end example in Idris, from fundamentals like building type-safe APIs, and performing IO through to building user interfaces. By the end of the talk we will have identified the strengths of this programming model, the practicalities of using them in Idris (in contrast to Scala and Haskell) and produced a battle-hardened, multi-player, tic-tac-toe game ready for production.

Template Haskell is a meta programming framework for Haskell implemented by the Glasgow Haskell Compiler (GHC), which is widely used as a template meta-programming system for Haskell, to define macros, code generators, or even code transformation engines. Subsequent support for the quasiquoting of arbitrary programming languages greatly simplified writing code generators in Haskell that produce complex C, CUDA, OpenCL, or Objective-C code by writing code templates in the syntax of the generated language.

Additionally, quasiquoting of C-like languages enables a purely library-based system for inline C code in Haskell. This dramatically simplifies language interoperability, and especially, the use of frameworks and libraries written in C-like languages from Haskell. It is, for example, helpful in applications based on native GUI libraries and projects integrating code written in multiple languages.

In this talk, I will explain the concepts of template meta-programming and quasiquoting and how they are used in Template Haskell. I will demonstrate quasiquoting by way of a few simple and intuitive examples. Finally, I will demonstrate the use of inline C code in Haskell and compare it to other forms of language interoperability as provided by Haskell and other functional languages.

This talk will explore the use, but not the implementation of quasiquoting and inline C & Objective-C code. Hence, the material should be accessible to anybody with an intermediate-level working knowledge of Haskell and C.

The complexity of web applications grows exponentially with time. Managing so much state in a modern single-page web application is challenging and difficult to reason about. Frameworks such as AngularJS and Backbone take some of that pain away at the expense of better abstractions and tight coupling between templates and display logic.

Facebook created React in an effort to mitigate this issue. It recognises how powerful the abstractions in functional programming are and let’s you write components which are simply functions from state to DOM sub-trees.

In this talk we’ll look at React through Om, a Clojurescript binding that further improves React’s performance by leveraging immutable data structures.

Free monads are a powerful technique that among other things, can separate the pure representation of code from its interpretation. The representation can be as sophisticated as any imperative program, but totally pure and typesafe! Not only this; once the concepts are understood, applying them is child’s play.

Here we provide an overview of the technique, and show how it can be used to write the AI scripts of a simple tank game in a totally pure and declarative way.

Functional Programming has shown the benefits of removing mutation and side-effects, resulting in programs fundamentally simpler and more composable. Nonetheless, many of these programs still rely on applying side-effects to external systems such as databases, file-systems or external services. This talk looks at applying these ideas to systems architecture, and how it can make whole systems fundamentally simpler to build, operate and reason about.

Functional approaches to architecture have other key benefits such as being naturally suited to audit and reversion of state to previous versions. They tend to have lower operational risk associated with them.

This talk looks at the history of systems built with an underlying functional architectures such as journaled file-systems and databases, event sourcing, and content-addressable storage, as well as the application of these ideas in programs such as Lucene and git.

We’ll see that there is an underlying philosophy of FP that can be brought to most aspects of system design and architecture, even while presenting a mutable face to the world.

This talk provides a whirlwind tour of some new types of functional data structures and their applications.

Cache-oblivious algorithms let us perform optimally for all cache levels in your system at the same time by optimizing for one cache for which we don’t know the parameters. While Okasaki’s “Purely Functional Data Structures” taught us how to reason about asymptotic performance in a lazy language like Haskell, reasoning about cache-oblivious algorithms requires some new techniques.

Succinct data structures let us work directly on near-optimally compressed data representations without decompressing.

How can derive new functional data structures from these techniques? Applications include just diverse areas as speeding up something like Haskell’s venerable Data.Map, handling “big data” on disk without tuning for hardware, and parsing JSON faster in less memory.

But the MapReduce computing model is hard to use. It’s very course-grained and relatively inflexible. Translating many otherwise intuitive algorithms to MapReduce requires specialized expertise. The industry is already starting to look elsewhere…

However, the very name MapReduce tells us its roots, the core concepts of mapping and reducing familiar from Functional Programming (FP). We’ll discuss how to return MapReduce and Copious Data, in general, to its ideal place, rooted in FP. We’ll discuss the core operations (“combinators”) of FP that meet our requirements, finding the right granularity for modularity, myths of mutability and performance, and trends that are already moving us in the right direction. We’ll see why the dominance of Java in Hadoop is harming progress. You might think that concurrency is the “killer app” for FP and maybe you’re right. I’ll argue that Copious Data is just as important for driving FP into the mainstream. Actually, FP has a long tradition in data systems, but we’ve been calling it SQL…

The world of Copious Data (permit me to avoid the overexposed term Big Data) is currently dominated by Apache Hadoop, a clean-room version of the MapReduce computing model and a distributed, (mostly) reliable file system invented at Google.

The goal of the talk is to demonstrate non-trivial uses of QuickCheck for testing Haskell programs. Outside of papers and book chapters, most of the information on QuickCheck only covers very basic usage. This talk is about the more advanced uses of QuickCheck, including the use of QuickCheck with monadic code, as well as how QuickCheck can be used in the parallel development of code and specifications.

The talk will begin with a very brief overview of the usual basic level QuickCheck as described in Real World Haskell and various sources on the internet. This will introduce some tests involving sorting and searching. These tests will be iterated on to demonstrate the development of QuickCheck specifications, along with some of the more advanced features of QuickCheck and how to avoid some common errors.

The next part of the talk will develop a purely functional queue and show that it is correct via both an algebraic specification and a model-based specification. This should give a really good feel for how to develop useful specifications and what they typically end up looking like.

The final part of the talk will cover the use of QuickCheck with monadic code. As well as demonstrating the use of the monadic interface to QuickCheck, this will work through a few small examples to help build an intuition for the kinds and scopes of problems which QuickCheck can be applied to.

Extended versions of the example code, slides and links to the reference materials used will be available via github.