Mark Engelberg Clojure/West 2017 Interview

Mark Engelberg will be giving a talk at Clojure/West 2017. He will be speaking about Solving Problems Declaratively.

Follow him on GitHub and Twitter.

PurelyFunctional.tv: How did you get into Clojure?

Mark Engelberg: Since 1998, I have been an independent freelance software engineer. Working independently, I needed to look for a programming language that would allow me to be maximally productive with as little fuss, as little overhead, as little boilerplate as possible. C++ wasn't going to cut it any more. For a while, Python was my high-productivity language of choice, but it wasn't ideal; I kept investigating functional programming languages because I sensed that the kinds of programs I was writing would benefit greatly from immutable data structures. As soon as Clojure emerged on the scene, I realized it was the language I had been waiting for.

PF.tv: What is your talk about?

ME: With the recent emphasis in the community on Clojurescript and cross-platform compatibility, it's easy to forget what Clojure brings to the table as a hosted language, and the value we can get from embracing the underlying language for maximum performance. I'm going to demonstrate how we can harness speedy solving engines written in Java, using Clojure libraries that allow us to formulate a declarative description of our problem and then manipulate that data into a form appropriate for the underlying engine.

PF.tv: Who is your talk for?

ME: This talk is suitable for all Clojure programmers. It will be especially enjoyable for people who like puzzles and other combinatorially complex problems.

PF.tv: What do you hope people will take away from the talk?

ME: There's a pretty wide range of problems that can be mapped to one or more of the solving engines I'll be talking about, so I'm hoping some people will say, "Hey, that applies to a problem I've been working on!" and will immediately have a new set of tools they can apply. Others, I hope, will be inspired by the underlying message of the talk to build their own Clojure wrappers around powerful Java tools.

PF.tv: What concepts do you recommend people be familiar with to maximize their experience with the talk?

ME: The underlying principles of SAT solvers and Constraint Programming have been covered at previous Clojure conferences, so I won't be rehashing those details here. I'll summarize the most important points, but for the curious, those would be good concepts to review.

PF.tv: What resources are available for people who want to study up before the talk?

ME: SAT Solvers - "A Peek Inside SAT Solvers" from Clojure Conj 2016. Constraint Programming - The second half of "Solving Problems with Automata" from Clojure Conj 2015.

PF.tv: Where can people follow you online?

ME: I am at @mark_engelberg on Twitter.

PF.tv: Are there any projects you'd like people to be aware of? How can people help out?

ME: github.com/engelberg/tarantella github.com/engelberg/rolling-stones github.com/aengelberg/loco

I hope to cover all of these in my talk. Some of these Clojure libraries only expose a subset of the functionality of the underlying engine. Contributions that help bring more of those features to the surface in a Clojure-esque way are encouraged.

PF.tv: Where do you see the state of Clojure in 10 years?

ME: It seems clear that data science, machine learning, and artificial intelligence are going to be the most critical fields of the next decade. I think Clojure's fate will be tied to its ability to make meaningful contributions in these areas. Clojure has already proven itself an adept language for understanding and working with data. However, its biggest weakness is number crunching --- as soon you store a number in a Clojure collection it gets boxed, which is devastating for performance. And unfortunately for Clojure, number crunching is at the heart of modern machine learning and AI techniques. Unless Clojure makes big strides in this area, I fear it may lose much of its market share to dynamic languages hosted on C, like Python and Julia.

It's always hard to guess Cognitect's future agenda, but given that they focus heavily on the needs of businesses, and given that business programming is becoming inextricably linked with number crunching, I think it's likely they see this paradigm shift coming and will want to address it. It wouldn't suprise me at all if in 10 years, the most popular flavor of Clojure is a Clojure for the LLVM, and we have a variety of new language features for dealing with primitive collections and matrices.

PF.tv: If Clojure were an animal, what animal would it be?

ME: A sleek and agile otter riding the waves.