EuroClojure 2016 was held in Bratislava, Slovakia on the 25th and 26th of October. Solita was not only one of the sponsors of the event, but also sent the five of us to attend. EuroClojure did not disappoint, and was full of interesting talks. This blog post is an overview of the presentations and will hopefully help you decide which ones you’ll want to eventually watch on Youtube.

Now what? David Nolen

The rock star of ClojureScript kept the title of the talk unknown until the first slide, even Justin Gehtland who presented him didn’t know the title :). The talk was mostly a continuation to clojuTRE, a reflection on the pillars on top of which ClojureScript stands. Google Closure is still a good bet with surprisingly low amount of competitors, and has had advanced features like funtion level code splitting into modules for even 5 years (see discussion on rollup on how JS scene is catching up). The output of Closure compiler runs on very old devices, including mobile phones, so the story is valid there too.

React has also been a good pillar to rely on in ClojureScript. Relay, GraphQL and Github’s GraphQL API were also mentioned.

ClojureScript is well past the quick death phase and the approach of not going for ease seems to have worked. A quote to remember was: “Ease tends to corrupt, absolute ease corrupts absolutely”

Going forth, Nolen encouraged to go and conribute to ClojureScript. There is a lot of potential to bring it forth while JavaScript land is growing in complexity.

Clojure is Not Afraid of the GPU, Dragan Djuric

Dragan gave a really interesting talk about several libraries he has written.

The first one was ClojureCL, which provides a nice interface for performing OpenCL computation on the GPU. It seems to significantly reduce the amount of boilerplate in a typical OpenCL C program and makes it nicer to interface with the GPU (or some other device supporting OpenCL). The actual OpenCL kernel functions still need to be written in OpenCL C, but ClojureCL seems to make all the resource management and communication aspects of OpenCL a lot nicer.

Next up he introduced Neanderthal, which is a fast matrix and linear algebra library for Clojure. This was, of course, written using ClojureCL and takes heavy advantage of GPU when available. This provides a significant performance boost when compared to CPU-based approaches, up to 1000 times faster. So, next time you need to do some matrix or linear algebra computations, keep Neanderthal in mind and make sure to get a fast GPU.

The last library he introduced was Bayadera, a Clojure library for Bayesian Data Analysis and Machine Learning. This uses both of the previous libraries and seemed to be, again, really performant. On some of his benchmarks, it was 7000 times faster than Incanter, another Clojure library for machine learning.

Dragan also gave two book recommendations. If you want to learn more about OpenCL and GPU computation, he recommended OpenCL in Action and also provides ClojureCL versions for the books examples. He also recommended Doing Bayesian Data Analysis for learning Bayesian data analysis.

Documentation for all of these libraries is available at uncomplicate.org.

Living with spec, Simon Belak

Simon gave a journey on the ideas he had gotten while applying clojure.spec to their analytics pipeline. He mentioned that since the project isn’t similar to a single application, the findings might be a bit different. In his view, while Lisps have been traditionally in the System Paradigm (high level language but hosted and direct access), spec moves more to the Language paradigm.

One interesting thing was the use of clojure.spec for automatic materialized view generation. Simon seems to be one of the users of Onyx framework, which in itself is also quite interesting and was discussed later in the unsessions.

A tale of Clojurescript in Production at a Payment Company, Jean-Louis Giordano

This presentation was an experience report on moving from Ruby to ClojureScript. Jean-Louis talked about what their experience at Zimpler was like, why they chose ClojureScript, and how they evolved their tooling and workflow as they learned more about the Clojure ecosystem. These kinds of talks are helpful in bringing more people into Clojure.

One interesting angle this talk had was the experience of the designers at Zimpler. At first they used Enfocus, but to better integrate the designers’ and developers’ workflows they moved on to Kioo. Currently they’re experimenting with having their designers write React component’s in JSX. Like Jean-Louis said, a designer doesn’t become a better designer by learning ClojureScript, so they have no incentive to do so - but the team still has to create the best possible workflow.

Clojure is a Foreign Country: Combining Datomic with Scala, Peter Brachwitz

This presentation was a tale of using Datomic from a language other than Clojure. Peter gave an overview of Datomisca, a Scala library that has novelty of interpreting Datalog query with a Scala macro, and Molecule, a Scala library that has a more Builder -like DSL for constructing Datalog queries.

Peter presented how the neater side of features of Datomic had worked for them. For example, a requirement password change not allowing old passwords comes naturally from keeping all history. Speculative transactions allow to catch validation errors early in client side, in contrast to running code in a normal database server side. Time travel and transactions being just data got also mentioned.

On not so neat side, Datomisca’s macros don’t work for dynamic queries (see slide on string concatenation :)) and they ended making their own ORM for Domain entities, which led to a lot of code that “deals with moving buckets, when you wanted water”.

He still concluded that general cross pollination of ideas from different poeple is good (lookup refs appear elsewhere too).

Machine Learning with Clojure and Apache Spark, Eric Weinstein

Eric presented quite a bit of background behind decision trees and neural networks and how he used them for the datasets he had. Eric also went through the basic components of Apache Spark: RDDs, Datasets and DataFrames. Spark has two notable Clojure wrappers, Sparkling and Flambo. They both offer quite similar interface, probably because both are quite thin wrappers. There wasn’t that much Clojure code on the slides, and the talk itself was quite relaxing. One has to mention his coffee cup though, which sparked a discussion on the slack channel on when he’ll finally take a sip :)

ClojureBridge Europe, Malwine Gier & Arne Brassuer

ClojureBridge is a community aiming to increase diversity within the Clojure community. So far the most popular way to achieve that goal has been organizing programming workshops for women. In fact, Solita has been a part of such workshops in Helsinki, Tampere, and Oulu!

The talk was interesting to anyone thinking about organizing a ClojureBridge workshop, and to anyone looking for extra tips on how to make their workshop better. I remember one slide in particular: it outlined three challenges that participants face, and the workshop should aim to answer.

GeoRepl - Interactive Geometry with Clojure, Thomas Neuhalfen

Thomas showed an application for drawing geometry by detecting gestures but also with access to the drawing from a REPL. This reminded me of Bret Victor’s work, but with a more REPL like approach. One could draw shapes and edit them with gestures (like cutting end of lines with a swipe) and refer to them from the REPL for manipulation (scaling, rotation) and grouping. Seems that there are quite a few planned features, which will give the system more appeal.

One interesting aspect of this talk was Thomas’ experience with using Clojure, and functional programming in general. He has been programming for a long time now, but he prefaced his talk by saying that he is not a professional software developer. He claimed however, that the functional programming model seemed to guide him naturally towards good abstractions. For example, he realised that he has a model where he can easily compose more complex geometries from simpler ones, and an undo stack was very straightforward to implement thanks to the immutability of Clojure.

Priority Search Queues: 1.5 dimensional Tree Search, Michal Marczyk

Michal gave a presentation about Priority Search Queues and his Clojure implementation of them. So what is a Priority Search Queue? It is a data structure that allows elements to both have a comparable key, like you have in a binary search tree, and also a priority, like you have in a priority queue. The advanced operation that this structure allows is to find all elements with key between a (min, max) range and priority below a maximum. And this search takes time proportional to the amount of elements that have all of these properties.

This allows you to perform an interesting geometric search. If you have a bunch of points [x y] , you can find all of the points with (<= min-x x max-x) and (<= y max-y) quickly.

The current implementation is at Github. He mentioned Ralf Hinze’s paper A Simple Implementation Technique for Priority Search Queues. I believe his implementation is based on this paper, but can’t remember for certain.

Communicating Risk Reactively, Mike Pearson

Another experience report on using Clojure, this time the subject was a project that “medical animation of risk adjusted mortality data, and rapidly morphed into a single page web site tackling some controversial and tricky issues”. Mike was a skilled presenter, and the subject was interesting: the researchers wanted to visualise data about the success different UK hospitals have on child surgery. The talk hardly mentioned Clojure at all, and was more focused on the difficulty of presenting such sensitive data in a fair and clear manner. A very enjoyable presentation, and one that is worth looking up on youtube if you’re interested in data visualisation.

Automating Resilience Testing with Clojure and Docker, Daniel Lebrero

Daniel started with a story on the road on which many working programmers have visited, after finally re-implementing a misbehaving library:

Daniel took to the heart the advice on test harness given in Michael Nygards book Release It!. He showed how such harness was created with a Clojure library called IG Havoc, which can control a set of Docker containers defined in a Docker Compose file. It was neat to see the NetEm support of Linux traffic control brought to bear to simulate service problems, in addition to stopping/starting services.

The most interesting thing was the above applied to property based testing, with a test.check generator that generates random commands to break the system. Although this doesn’t prove that the system is without error, and running the tests may take a while, it was neat to see that they found real issues. Personally, I’d think that such a system control is useful even without generative tests.

Bare Metal Clojure with clojure.spec, Michael Reitzenstein

Michael demonstrated his work in progress Clojure to C compiler that makes heavy use of clojure.spec generators.

His compiler uses the generators to generate inputs for functions, which are then used to optimize and specialize functions based on those inputs. He showed examples where a function doing lots of arithmetic had to originally perform lots of unboxing and boxing of numbers and the compiler transformed it to a function doing only primitive arithmetic. In this case the compiler has to change the call sites to do the unboxing and boxing. His methods seemed to work very well in this context.

Another example involved doing compile time memoization, again using generated inputs, to improve performance while increasing size of the binary. This left me wondering how far the compiler would be willing to take this approach, it might make the binaries unwieldily large in some cases.

These methods depended on the generated inputs being representative, so it requires some care from the programmer to write good specs. The approaches seemed interesting in taking advantage of input generation for program optimization purposes. The compiler was still a work in progress and will be released later.

Making Machines that Make Music, Srihari Sriraman

Unfortunately we missed the beginning of this presentation, because we wanted to eat lunch in a proper restaurant, which took a bit longer than we thought. Many people commented afterwards that Srihari’s presentation was one of their favorites from the whole event, and it’s quite easy to see why: his presentation style was easy to follow, and personally I very much enjoyed how he presented his gradual progress towards his current solution. If you’re interested in generating music with code, machine-learning, or just learning about Indian Carnatic music, I encourage you to watch this talk!

Live-coding Mathematics: Your First Clojure Proof, Frederic Peschanski

This presentation continued the tradition of live-coding logic systems, resembling last year’s μKanren talk by Bodil Stokke. Like Bodil, Frederic used the power of Emacs to conduct his live presentation :). He presented LaTTe (a Laboratory for Type Theory experiments), a proof assistant library written entirely in Cloure, which makes it only a vector of [latte “0.3.7-SNAPSHOT”] away from your project.clj. He showed how in LaTTE one can express logic from the Aristotle’s reasoning of Socrates being mortal to injectivity. The presentation itself is available as a Leiningen project at https://github.com/latte-central/latte-euroclojure-2016, so trying it out while watching the video of the presentation might make for a good learning :)

A Case Study of Natural Language Processing in Clojure, Daniel Janus

Having seen a presentation about machine learning already made the angle of this talk curious. Daniel had a very detailed look on what it took to process a corpus of the Polish Parliamentary Proceedings. The corpus itself is a website, which requires scraping. Although this might seem easy at first, this turns out to be more complicated, since the site has navigation designed for humans, which the scraper program has to follow. This was accomplished with a library called Skyscraper, offering ways to specify traversal, capturing and caching of the scraping process.

When it comes to actual NLP, one can say only this:

Fortunately there exists stemming libraries for Polish (Finns have Voikko for that) that the Smyrna application uses. Smyrna itself is the app for searching the corpus data with a ClojureScript UI made with re-frame. One neat thing is that reading of the compressed corpus data is quite low-level endeavour and inner loops of the implementation make use of the lesser known :volatile-mutable metadata.

As to why not use Elastic/Solr, the author granted a NIH syndrome, but some of which is required for going deep :)

Genetic Programming with clojure.spec, Carin Meier

The keynote speaker was introduced by David Nolen, describing his colleague as someone who constantly applies new things in whatever she does. Caren used the division coined by the mathematician David Mumford to programmers: Explorers, Alchemists, Wrestlers and Detectives. Carin identifies herself as an Alchemist, and she conducted quite an alchemy with clojure.spec :) First one was using a genetic algorithm to generate a spec for a piece of data, by scoring specs on how much of data they could consume without error and then mutating, breeding and selecting evolution after another. But wait, the result can also generate data, for which a spec could be generated…

Next alchemy experiment took ideas from the MIT Codepage project for self-healing code. Clojure.spec was used to find a substitute for a function that throws an error (identifying the function from stack frames). The mechanics seemed a bit simpler than with the evolution experiment, but the neat thing was that dynamism of Clojure offers to override the misbehaving function.

The main theme of EuroClojure 2016 seemed to be on clojure.spec, and Carin’s talk ended with a challenge for all the other tribes to go forth and use it for a win :)