lvh Clojure/conj 2016 Interview

lvh will be giving a talk at Clojure/conj 2016. He will be talking about using C APIs from Clojure.

Follow him on GitHub and Twitter.

PurelyFunctional.tv: How did you get into functional programming?

lvh: I guess it depends a little on where you draw the line of what constitutes functional programming. I've had a few interactive environments that rely on functional programming languages, like Xmonad, stumpwm, and Emacs. I generally prefer the rapid feedback cycle you tend to get out of Lisps compared to the compiler focused languages like Scala or Haskell. I've also written some Prolog, (R4RS) Scheme and even a dab of Erlang. But if you're asking what I credit with getting "into" FP, it's definitely the language immersion of an environment like stumpwm. There's just something that clicks when you realize your environment is... "alive"? I guess there's a parallel to be drawn here with why a lot of power users prefer the command line: it's not just quantitatively "better", it's qualitatively different.

PF.tv: What is your talk about?

lvh: My talk is about writing Clojure (primarily on the JVM) that uses existing C libraries, or, arguably more accurately, "native code". I talk about why you might want to do that at all (it's not just performance, although that's one reason), how you'd do that (there are a few ways and not all of them are great), and why Clojure is a great language for doing that in. I've tried to keep that as generally applicable as possible, but I use my experiences binding caesium as a guideline for when I feel it'd be helpful to have a concrete example that isn't a "toy".

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

lvh: That Clojure is an excellent language for using C libraries, or at least that there's no Clojure-specific reason for restricting yourself to the host platform, like the JVM. Being a hosted language with excellent host interop has always been a core part of Clojure, ClojureScript and ClojureCLR. On the other hand, there are plenty of people whose experiences trying to get the JVM (typically Java) to use native code have been less than pleasant, so Clojure isn't known (yet!) for having excellent interop with native code. In recent years the JVM has received some new technologies that drastically change how practical it is to do this; and I'm here to convince you that Clojure's fundamental qualities (especially "have some data, then don't mess it up") can help supercharge that just like they do for everything else.

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

lvh: I go over some of the basics you need to know (like ways the JVM lets you interact with native code at all, like JNI, JNA and JNR). It'd probably help if you knew those existed before you came into the room. If you have some basic experience with C (say, you know how to print the output of gettimeofday to stdout), it probably wouldn't hurt. However, if all you know is Clojure, and you're willing to believe me that there is native code out there and your OS has a standard way to call it and you can do that from Clojure because I'm going to show you how, you'll probably be fine.

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

lvh: My slides are online; which might be helpful as a glossary of terms to search for.

PF.tv: Where can people follow you online?

lvh: Twitter is probably the best medium: I'm [@lvh]Twitter there and I have that user name pretty much everywhere :-)

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

lvh: Beyond a doubt: Cloverage! Cloverage is a code coverage tool for Clojure code. It's a great example of a useful project that doesn't seem to get enough love. It's gotten a bunch more attention recently; I've accidentally become its maintainer, and a few people (rm-hull in particular) have been tirelessly contributing patches and PRs. It's gotten a bunch of releases in the last few weeks. It does need more eyes though. There are a number of things that'd be great, with a reasonably maintained issue tracker (there are a bunch of tickets with great information on how to start). It feels like more projects should have a decent idea of just how good or bad their test coverage is, so it's a pity that this project doesn't get more attention than it has in the past few years.

You can find Cloverage here.

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

lvh: Well, prediction is hard, especially about the future.

I think that in the next ten months (maybe a bit longer) or so I'm most excited about how much extra power we get thanks to getting functional ideas in the browser (and, thanks to things like Atom Shell, on the desktop), thanks to ReactJS. Combining that with the usual Clojure goodness (macros, easy accessibility to usable asynchrony, pattern matching, logic programming), together with CQRS and Datascript, I think we have a lot of exciting times coming.

In the next ten years, the goals are a little more vague. I'm hoping we manage to make functional programming more accessible. In particular, I'd love to see more usable proof systems, that give you the benefits of having assurances about what your code does, while keeping the rapid feedback cycle I've come to love and, honestly, rely on on in Lisps.

PF.tv: If functional programming were a superhero, what superpower would it have?

lvh: I wanted to say "time travel" in the usual reductions sense, or per the analogy of the river. I guess you could do better than that, by having a superhero that can just evaluate the tree of every possible outcome with every possible choice and then pick the right one. On the other hand, that'd be kind of boring since they'd effectively be omniscient and omnipotent. To make it a good story, you'd want that to be a Cassandra-like figure that knows what will happen, but, tragically, nobody believes them, or they can't communicate it.