Despite Moore's "law", uniprocessor clock speeds have now stalled. Rather than single processors running at ever higher clock speeds, it is common to find dual-, quad- or even hexa-core processors, even in consumer laptops and desktops.

Haswell, Intel's forthcoming multicore architecture, will have eight cores by default. Future hardware will not be slightly parallel, however, as in today's multicore systems, but will be massively parallel, with manycore and perhaps even megacore systems becoming mainstream.

This means that programmers need to start thinking parallel. To achieve this they must move away from traditional programming models where parallelism is a bolted-on afterthought. Rather, programmers must use languages where parallelism is deeply embedded into the programming model from the outset.

By providing a high level model of computation, without explicit ordering of computations, declarative languages in general, and functional languages in particular, offer many advantages for parallel programming.

One of the most fundamental advantages of the functional paradigm is purity. In a purely functional language, as exemplified by Haskell, there are simply no side effects: it is therefore impossible for parallel computations to conflict with each other in ways that are not well understood.

ParaForming aims to radically improve the process of parallelising purely functional programs through a comprehensive set of high-level parallel refactoring patterns for Parallel Haskell, supported by advanced refactoring tools.

By matching parallel design patterns with appropriate algorithmic skeletons using advanced software refactoring techniques and novel cost information, we will bridge the gap between fully automatic and fully explicit approaches to parallelisation, helping programmers "think parallel" in a systematic, guided way. This talk introduces the ParaForming approach, gives some examples and shows how effective parallel programs can be developed using advanced refactoring technology.

Riak is one of the new breed of no-SQL database management systems, which has begun to replace relational databases for some applications. Riak is a distributed key-value store, inspired by Amazon’s Dynamo, designed for applications where scalability, low latency and high availability are critical. Riak uses replication to provide fast access to data, even when multiple nodes or parts of the network fail. It supports concurrent access to the same data by multiple clients, even when the network is partitioned. All of this makes it very hard to test.

Reducing over relationships in graphs takes our data to the next level. Persisting that to the database saves us impedance mismatch and the overhead involved in the mapping. In this session we will talk about Neo4j and how we can use cool ideas from graph theory to get more value from our data.

We are now used too being roused out of bed by news of the latest serious Internet security alert or major data leak. The software services we now use are tremendously complex, and mash together a complex spectrum of policy and mechanisms. I'll talk about a different approach to building networked services in this talk that cleanly separates both of these, and results in an extremely efficient deployment model that outputs standalone kernels straight from OCaml source code.

Hypervisors such as Xen or VMWare provide a flexible platform to host applications as a set of appliances, e.g., web servers or databases. Each appliance usually contains an OS kernel and userspace processes, within which applications access resources via APIs such as POSIX. It's on top of this layer that you typically write code in your functional programming language of choice.

Our Mirage operating system implements a radically different way of building these applications. Mirage supports the progressive specialisation of OCaml source code, and gradually replaces traditional OS components with type-safe libraries. This ultimately results in "unikernels": sealed, fixed-purpose images that run directly on the hypervisor without an intervening guest OS such as Linux.

Developers no longer need to become sysadmins, expert in the configuration of all manner of system components, to use cloud resources. At the same time, they can develop their code using their usual tools, only making the final push to the cloud once they are satisfied their code works. As they explicitly link in components that would normally be provided by the host OS, the resulting unikernels are also highly compact: facilities that are not used are simply not included in the resulting unikernel.

For example, the self-hosting Mirage web server image is less than a megabyte in size...

Implement trampolining IO! Traverse to your heart's content! Say "Applicative functor" like you know what it means! You know you want to.

We'll charge at high speed through the following topics, with Clojure code to follow along with as we go (because there's no better language for implementing a Lisp than another Lisp)

1. Parsing: turning text files into ASTs
2. Fundamental Lisp datatypes
3. McCarthy's elementary functions.
4. Evaluating Lisp code
5. Lambdas and lexical scope
6. Your friend, the state monad
7. Beyond Lisp: pattern matching and type systems

When we're done, you'll be ready to go forth and fill the world with Lisps of all shapes, colours and Greenspun violations for Great Justice. Also, it'll be good fun.

How best to blend a domain-specific language into a host language? For the domain of databases, the old question of how to achieve language integrated query is receiving renewed attention, in part because of its support through Microsoft's LINQ framework. Higher-order features prove useful even for constructing first-order queries. We prove a theorem characterising when a host query is guaranteed to generate a single SQL query, and we present experimental results confirming our technique works, even in situations where Microsoft's LINQ framework either fails to produce an SQL query or, in one case, produces an avalanche of SQL queries. Our ideas are implemented in F#, and the talk briefly considers how they might apply to other languages such as Scala and Haskell.

Many examples in functional programming assume that you are always on the "happy path". But to create a robust real world application you must deal with validation, logging, network and service errors, and other annoyances. So, how do you handle all this in a clean functional way? This talk will provide a brief introduction to this topic, using a fun and easy-to-understand railway analogy.