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