After enjoying the chance to experiment with Clojure on a couple of projects over the past year I thought this would be a good opportunity to learn more about the wider ecosystem.
The pace of the conference was great, with 15 min breaks after each talk, you had plenty of time to digest and recharge for the next one. The topics were varied and overall i'd recommend it to anyone curious about Lisps or functional programming.
You can watch all the talks here and below I have summarised a couple of my favourites. Hopefully it will encourage you to watch them in full!
Angular Must Die, Here Are Some Weapons (Kris Jenkins)
- Despite the combative title, this talk was more a discourse on what it means to create great software how we can improve on our craft as engineers. (Hint: Angular v1 was an example of bad software).
- Around 5 years ago, Kris hit a programming rut. He began to feel that all languages are essentially the same, that he could program anything he wanted to but couldn't muster the energy.
- Clojure re-invigorated his love of programming and taught him many interesting things - that programming is about ideas and Clojure has many great ideas.
- Syntax takes a secondary role to semantics and the deep ideas a language allows you to express.
- To illustrate this point Kris recommended creating a VM for the Brainfuck language which can be done in 90 mins and demonstrates that you can make Turing complete languages even with dreadful syntax!
- Kris then began to talk about how this formed his thoughts on what makes great systems and broke it down into 4 key considerations:
- Design - Has it been designed well?
- Data - Has the data been modelled well?
- Process Building - How is data transformed?
- Effects - How is the passing of time managed?
- Humans are the producers and consumers of systems and this is something we should always remember.
- Clojure is designed for humans. It's a tool that has strong answers to each of the areas above and can enable you to build great systems.
- Data is the biggest idea in programming - modelling data and transformation of data through pipelines. We describe the world then describe how it works.
- Describing and modelling data first is better and easier to evolve over time. It provides a picture of what you think the world is now.
- We cannot avoid side effects and we need to handle them carefully. We need to track and constrain what a function does and how it does it. Kris recommended reading up on Category Theory and Monads for more information on composing functions and tracking effects.
- To build great systems, take inspiration from the academic community. They don't sell their ideas particularly well but if you are looking for programming wealth, academic papers are fruitful mines.
- There are limitless new ideas to explore in computer science, the future is already here and we just need to crack it open.
- Be surrounded with your own ignorance and enjoy it!
Arachne: A Clojure Web Framework (Luke VanderHart)
- Wait, didn't we start using Clojure to get away from frameworks!?
- Luke certainly did but through years of working with Clojure at Cognitect, he gradually began to feel that Clojure was lacking a high productivity web framework.
- Through prior experience with frameworks like Rails - which focus on productivity and convention over configuration - he began to think about the benefits of frameworks and how they affect your productivity as a project scales.
- To visualise the problem he presented this superb slide which I think is right on the money:
- From this you can see where Luke wants to position Arachne. Perhaps more effort to start than something like Rails but significantly less than stacking together Clojure libraries. As the project scales, the effort to develop with it should increase linearly and not excessively penalise at some breaking point.
- He then gave an excellent breakdown of the difference between libraries and frameworks.
- What do each provide for you as the developer? Well if we think of a system as a tree:
- With libraries, the programmer writes the trunk of the tree, the libraries are then the branches and leaves that you plug in where needed. You drive the application and you call the libraries.
- With a framework, the trunk of the application is written by the framework, you then write the branches and leaves of the tree. The framework drives the application and the framework calls you.
- There is an inversion of control: A library says "here's a thing", a framework says "do it like this".
- Benefits of frameworks:
- Modules in frameworks are aware of other modules because they are aware of the trunk, they are part of the framework.
- Libraries are not aware of the trunk, they are meant to be used independently, you have to do the work of feeding it data.
- You don't need to know all the common libraries when using a framework - the common stuff is built in.
- Luke argued that there is a lower cost to switch modules compared to switching libraries because of this.
- Frameworks have the opportunity to be secure by default because they control the trunk of the application.
- With a framework you can talk about more abstract level application concepts, you begin from a higher starting point whereas libraries focus on language concepts, they are about code.
- Downsides of frameworks
- Often heavyweight, all or nothing solutions, you need to buy in to the frameworks conceptual approach, the application concepts. You buy MVC if you use Rails.
- With a fairly convincing argument for frameworks, Luke then introduced Arachne with the key goals of rapid web development and modularity in Clojure.
- Check out the Hello World application and see what you think!
- Most Real Talk: Living Clojure (Jon Pither). The power of Clojure and tips on selling the enterprise. Don't give up hope!
- Most Intriguing: Mutant Tests (Jan Stępień): Who is testing our tests? With mutation tests, you can generate faulty versions of your code and see if tests still pass!
- Most Simulations: The Territorial Prisoner’s Dilemma (Peter Westmacott): Classic Game Theory in the form of a territorial tournament. Who knew there were so many strategies for cooperating or betraying?