The adventure continues.

Day two started with the keynote by David Nolen about Invention, Innovation & ClojureScript. After some interesting discussion on the difference between invention and innovation, he talked about the history of clojurescript, a clojure implementation that does not target the jvm but javascript as a runtime environment. It was released 3 years ago and since then undergoes constant innovation. To date, the innovations come from 81 different contributors. Examples for contributed innovations are persistent immutable datastructures and source maps, which are very useful for debugging clojurescript. David introduced the basics on react.js and then of om Om is a clojurescript library on top of react.js. It adds a key ingredient to react: Immutability. By having an immutable global application state, communication between components becomes feasible without any of those crazy interactions, that make classical user interface development so hard. As an example David  showed Goya a pixel editor for the browser. Due to clojurescript's persistent datastructures it features undo/redo of a virtually unlimited number of steps with little to no performance impact at all. David finished with an outlook on clojurescript 1.0. Among the goals is better code sharing between clojure and clojurescript.

Next was Ali Asad Lotia talking about why devops need clojure. In his talk he cited Alan Kay who once said "Lisp isn't a language, it's a building material.". Ali's whole talk was a testimony to that statement. He showed how clojure can be and is used for any devops task. Release automation, configuration, performance measurement, metrics, log handling and what not. In his company the platform engineering team is responsible for those things. He showed how his team solved a lot of those problems with clojure. Starting with getting rid of mutable deploys, having an automated system knowledge base, that knows about all the machines and their respective deployments. Using riemann for collecting metrics and statistics.  Ali's team has all those tasks unified with clojure. All those tasks were also solved well by our platform engineers at Otto but not with such an homogenous toolset. Ali is looking forward to the fastloading feature of clojure 1.6. Using clojure for scripting should be a lot more fun without having to wait for the jvm startup.

Stuart Sierra's talk about his component library and how it adds just enough structure to programs written in clojure was the one I personally was looking forward to the most. Stuart started with the usual architectures of applications. The 3-layer architecture which is designed upfront and the x-layer y-component mess of an architecture that usually comprises the resulting product. Such architectures consist of a lot of elements. Many of them, like databases or e-mail services, stateful in nature. By Stuart's definition a component is"a collection of functions or procedures which share some runtime state."Usually Object Orientation shines at mapping such elements to code. In clojure, where we do not have objects, the component library can help in defining such collections of functions, managing the lifecycle of stateful resources and the dependencies between them. A system map holds the different components and initializes them in the right order. As the system map is just a plain map and it brings all of a maps convenience . It is easy to replace components with mocks for testig purposes. You can even merge two system maps and let two small systems form a bigger system together. Local development can happen with the merged system, while the smaller systems might be deployed separately e.g. into a cloud of sorts. Using components does come with a price as you will have to design your app around them. I think the component library will become very handy when developing small and medium sized web services. Read on for a great follow up on Stuart's talk.

Next was Philip Potter who talked about generative testing with clojure.test.check I heard about generative testing before and I have to admit I was a little sceptical about it. Philip managed to totally change my mind. Here is how generative testing works: When you are about to test a function you create a random generator for the input of it. You define how many different combinations should be tried. And you add an assertion for the correctness of the output. Such randomly generated tests will be able to hit a lot more edge cases, than handwritten unit tests ever could. When testing a function that sorts lists of integers for example, the random generator would be composed of one for random lists and one for random integers. In clojure it looks as dead simple as this(def my-generator (gen/list gen/int))The test will then be applied to a number of random inputs. If you want to repeat a test run, you can. By using the same random seed. As if that was not cool enough on its own, there is also shrinking. That means, if an input makes the test fail, the library will systematically shrink the input to the smallest input that still fails the test. This makes understanding the failing test a lot easier. The minimal failing input can become the input for a new unit test. Philip mentioned a ton of other cool features. Among them converting a schema definition (see Tommi's talk on day one to testgenerators and most impressive generating parallel input sequences to find concurrency issues.

Chris Ford's talk on the Curry-Howard Correspondence was refreshing because it was not about clojure. It was a about type systems. The Curry Howard Correspondence says, that functions can be used to prove type propositions. Admittedly I did not understand all to much of that part, but: Type systems can prove that your code is mostly harmless. They usually do not protect you from errors like passing nil (or null) to a function that expects a value of a given type. Similarly it does not prevent out-of-bounds exceptions when trying to access the members of an empty list. Except they are advanced type systems like that of Idris a haskell dialect made by Edwin Brady, the creator of whitespace himself. Idris was made to create a better type system and to finally have a vantage point from which to scoff at the haskell programmers. Idris' type system will prove at compile time that you never pass an empty vector to functions like e.g. head or tail. Adding a vector of typeVec 3 Intto a  vector of typeVec 4 Intwill result in one of typeVec 7 IntI seriously don't know whether programming with such a strict type system can be any fun Chris' talk however was a very interesting and entertaining excursion and it reminded us all how far you can get without any type checking, when your language is well designed.

After that rather theoretical talk Anna Pawlicka followed with a very hands on presentation on reactive data visualizations with om. Anna looked a little deeper into react.js and om than David did in the morning. She showed leaflet.js and dimple.js two higher level libraries on top of D3 that she uses for graphing data and visualizing maps. She demonstrated, how due to the efficient dom manipulation of react.js, it is possible to just redraw graphs instead of applying complicated changes to them. Together with the global immutable application state of om, and the persistent data structures of clojurescript itself this results in that same undo/redo capabilities I already found so astonishing in the morning. Anna's talk was full of example that demonstrated, how little code you have to write and read when working on such advanced applications.

Gergely Nagy talked about the face of inspiration or how clojure brought lisp to the python world. Gergely is one of the creators of Hy a lisp dialect targeting python. Hy is very much inspired by clojure. Its syntax is similar to that of clojure and the implementation of many useful functions was ported from clojure to hy. E.g. that is a lot of functions from core.logic and algo.monads Hy is a python abstraction syntax that is mapped into regular python code. As such it is lacking one thing that makes clojure so outstanding. The persistent, immutable datastructures. On the plus side it has python interop (naturally). As another plus, Gergely's talk was great fun and it even had a pony. But only one. So if you really like ponies, you might prefer bodol over hy.