Your current filters are…
by Bodil Stokke
The programming paradigms that served us so well through the 80s and 90s are failing us. Building systems the way we're used to building them always seems to end in the inevitable death march towards exponential complexity. But once you stop to ask the right question- "what's really causing all this complexity?" - you realise the answers have really been staring you in the face all along. Debugging is only hard when you can't reason about your code. Concurrency is only hard when you can't predict the state of your code. Reusability is only hard when your components aren't naturally composable.
Fortunately, languages addressing these issues specifically are popping up all over the place. In many cases, it turns out we've had the solutions to our problems for a long time, we've just forgotten about them, or never really bothered to look. Let's take a moment to explore some of these languages, not as exercises in syntactic details, but looking at the inherent properties in their design that enable us to defy decades of OO tradition and write honest-to-Dijkstra bug free, fault tolerant software without even trying. After half a century in the wilderness, functional programming seems to finally be gaining some ground on the barbarians. Let's examine why.
You are a Clojure newbie who has a firm grasp of the sequence abstraction and have been mapping and reducing like a pro, enthusiastically solving project euler and 4clojure problems. Life is good and producing a fibonacci sequence has never been so much fun. However, the time has come to produce a web app but you are not sure where to begin! Does functional programming work on the web?
This tutorial will provide an introduction to web development in Clojure for beginners, using a monitoring dashboard as the vehicle.
There will be a break for lunch part-way through the session.
Clojure is a relatively new language, so what will legacy Clojure applications look like, and how will they be to work with? How will you bring a new developer up to speed with your complex ecosystem of Clojure applications? What happens to your code base when you have a number of experienced developers new to Clojure working on it?
At uSwitch, we deployed our first Clojure application in early 2010. Since then, we've been happily leveraging the power of Clojure to solve problems and improve our business. Many different systems and applications have been built, by different developers, at different stages in their Clojure learning journey.
We will quantify how our use of the language has changed throughout that time, and point out the various techniques which have allowed us to avoid a confusing clash of paradigms. Using and presenting the torch analytical library built on top of codeq and datomic we examine a number of “legacy” Clojure systems, and discuss how our patterns of writing code have evolved.
We will explore the experiences of the developers who inherited the large scale, business critical Clojure applications along with the experiences of the developers who originally wrote the system, whilst exposing some of the WTF moments/mistakes we made along the way. Which parts are easy or difficult to understand or reason about, and what are some of the attributes that make it so?
by Joseph Wilk
Over the last year Joseph Wilk has been introducing Clojure into SoundCloud. Over this time we have been refining the blue-print for services functioning under high load with a strong focus on fault tolerance. We will explore how we use Clojure at SoundCloud, the power of focusing around the JVM and real examples where Clojure fit and where it failed.
Moving from OOP to FP often removes complexity, making code easier to write, read and reason about. The paradigm shift has enabled programmers to be more productive, and hopefully it has made people more open to reconsidering the fundamentals of the tools they use to solve problems. The question is: what is the next big paradigm in programming? and how does it relate to FP?
Logic programming (LP) offers a declarative way of programming. The shift from FP to LP is very similar to the shift from OOP to FP, in that is makes programs more declarative and easier to reason about.
core.logic is a Clojure library which enables programmers to write logic programs in Clojure by combining principles from both OOP and FP with logic programming. In this hands-on session we are going to help you through understanding the fundamentals of core.logic, and to write your first logic program on your own machine. We assume you have some (but possibly very little) experience with programming Clojure or another Lisp, but no prior knowledge of any logic programming is assumed.
The goals of the session are to enable you to:
* Use fundamental tools in logic programming
* Combine FP, OOP and logic programming in a single codebase
* Identify which problems are well suited for logic programming, and which are not
* Solve a set of problems handed out by the end of the session (at your leisure)
by Sam Aaron
The term "programming language" is often used to describe the medium we use to communicate with computers. However, to what extent can we also use programming languages like we use regular language? For example, could we use them to directly share ideas and thoughts with other people? Could programming be as live as a regular conversation? To what extent would such a live programming environment be ripe for mining novel ideas that would not only benefit the computer industry as a whole and yet even support artistic practices?
This talk will explore these questions in detail emphasising the role and importance of functional languages in this context. What might a programming environment which has sufficient liveness, rapid feedback and tolerance of failure look like? Could we make such an environment live enough to support music performances? What benefits would such a style of programming offer business? Could live programming be beneficial for rapid prototyping, exploring big data sets, and even communicating formal business ideas?
24th–25th October 2013