Howard Lewis Ship Clojure/West 2017 Interview

Howard Lewis Ship will be giving a talk at Clojure/West 2017. He will be speaking about GraphQL in a talk titled "Power to the (Mobile) People: Clojure and GraphQL".

Follow him on his Homepage, GitHub and Twitter.

PurelyFunctional.tv: How did you get into Clojure?

Howard Lewis Ship: I was speaking at a No Fluff Just Stuff conference in Boston, in 2009 I believe, and having dinner with Stuart Halloway. So, when Stuart leans across the table and says, "Howard, there's two things you need to learn: Git and Clojure" I listened --- you really can't get it from much closer to the source than that!

I think I had stumbled on the nascent Clojure home page a few weeks earlier, but sort of dismissed what I saw as just Lisp syntax for Java (reminiscent of when I chose not to pursue Ruby in 2000 because I didn't like underscores in the method names!). I hadn't seen Lisp code since a short course I took in college.

But with Stuart's strong recommendation, I came home, and started tinkering with Clojure. I think my first example code would identify how to score a hand of Cribbage. I didn't get to pursue Clojure in any active way for a few years after that, I was very busy writing Apache Tapestry and Tapestry applications for clients, but I jumped at the opportunity when it came.

PF.tv: What is your talk about?

HLS: My talk introduces GraphQL, an emerging specification from Facebook, that is effectively an alternative to REST and all kinds of ad-hoc JSON-over-HTTP approaches. I called the talk "Power to the (Mobile) People" because many of the features of GraphQL put the client, especially the client in a bandwidth restricted mobile device, in charge, ensuring that communications between client and server are efficient. A lot of the ideas behind GraphQL, such as the focus on data and the shape of data, will be very familiar to the Clojure community.

In addition, we'll be introd ucing Lacinia, our open-source GraphQL implementation written in Clojure. We're only just cleared the last hurdles of Walmart bureaucracy in getting that out and up on GitHub. Lacinia has been under development since before I joined Walmart, and is used in production and at scale. For example, if you've ever used the Walmart mobile application to look at your transaction history, that's GraphQL and Lacinia under the hood.

PF.tv: Who is your talk for?

HLS: My talks are almost always targeted at developers. The goal of the talk is to identify the kinds of frustrating challenges we find when developing web services, the frustrations that are so common that we no longer notice them ... then show how GraphQL addresses those challenges, and how the GraphQL ideas are expressed using Lacinia.

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

HLS: For me, GraphQL and Lacinia are a matter of "having your cake and eating it too". There's a few tradeoffs in taking this approach, but they mostly fall into the edge cases. For the most part, you end up with less code, more agility, better (live!) documentation, and better throughput. If I can get these ideas across to my audience, then I'll have achieved my goals for the talk.

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

HLS: The beautiful thing about GraphQL is that there isn't that much there. It's a bit like Clojure, a few simple ideas that reinforce each other to great effect. If you've ever built even the simplest web service, you'll find the problems GraphQL addresses familiar, and be able to appreciate the solutions GraphQL provides.

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

HLS: Lacinia should be up and out soon, with rather nice documentation. GraphQL itself is very well documented, and the specification itself is quite readable.

PF.tv: Where can people follow you online?

HLS: I'm @hlship on Twitter. I occasionally blog on Medium.

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

HLS: My crusade in the Java world, and more recently in the Clojure world, has been about feedback. For me, a narrow definition of feedback is the ability of the system to describe its current state, especially in the case of an error, in a way that is useful and easily digested by a developer.

Apache Tapestry (a component based Java web framework) spearheaded this with a rich and detailed exception report page, plus many, many more features so ensure that useful data could be presented on that page. In the Clojure world, the io.aviso/pretty library has proven to be very popular: it's primary purpose is to hook into Clojure exception reporting and neaten things up: invert and compact the stack trace, de-mangle the Java names back to Clojure names, organize everything into neat columns, and so forth. In the rare times I go back to Java code nowadays, I really miss pretty!

A few of the other things I've open sourced since joining Walmart also fall into the feedback category, including vizdeps, which visualizes project dependencies and helps you identify conflicts.

We use a little bit of everything on our projects, so I'm hesitant to produce a big shopping list. I would specifically call out Stuart Sierra's Component library as something we use and depend on.

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

HLS: I've worked in a variety of languages and environments, but despite some warts and frustrations, I've never worked in anything that felt as direct and productive as Clojure. I think Clojure on the JVM is going to stay the primary platform for Clojure, but we've seen ClojureScript go from a prototype to an amazingly successful tool in just a couple of years. Meanwhile, there's serious work to keep Clojure active and up-to date on the CLR, and interesting projects such as Joker (by team member Roman Bataev) that, again, implement some or all of Clojure for other platforms. So I think Clojure is going to be an ever widening family of languages, and that's going to create both successes and problems.

I'm afraid I don't see Clojure escaping its niche status. I expect that I'll start teaching my now 7 year old son, and now 4 year old daughter, Racket when I try to get them interested in coding ... not Clojure, which comes with all that JVM baggage. So I think the pool of Clojure developers will stay very small compared to the pool of Java developers for the foreseeable future. The question is: is that a bad thing? I think there will always be a limited pool of the very best developers: the self-starters, the deep-thinkers, the risk-takers, the mentors and leaders. Currently, those people are attracted to Clojure because it provides the path of least resistance between their ambitions and what they can actually deliver. What's important is that the next wave of such developers are exposed to the message and promise of Clojure and come into the fold. Knowing how to code in Clojure isn't a super-power; coding in Clojure unleashes your super-powers.

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

HLS: In some of my talks, I've described Clojure as a Chimera: a mythical beast that merges together a lion, snake, and goat (or any number of different creatures, depending on the tale). But for me, that's the essence of Clojure, a blending of two different lines: one from the C heritage as Java and the JVM, and the other heritage coming from Lisp and Scheme. Like the Chimera, Clojure is more than the sum of its parts.