Andrew Mcveigh :clojureD 2017 Interview

Andrew Mcveigh will be giving a talk at :clojureD 2017. He will be speaking on how clojure.spec works.

Follow him on his Homepage, GitHub and Twitter. How did you get into Clojure?

Andrew Mcveigh: In about 2008/9 I was writing web apps in C#. I started hearing more and more about functional programming on blogs and podcasts. I first tried F#, but I didn't really enjoy the ML style syntax back then, and I wasn't much a fan of .NET or Visual Studio.

I'd also wanted to learn a lisp for a while, so when Clojure was starting to pick up traction somewhere around 2009/10 I gave it a try. I immediately liked the language, and loved the REPL. Clojure seemed to be the language that fit how I thought programming should be. Within maybe a few months I felt more productive, even though I didn't know that much of the language, and there wasn't much tooling around at that point.

I introduced Clojure where I worked by writing a job that extracted data from loads of Excel spreadsheets and put it into a database. It was so much quicker and easier than working with C# they saw the value straight away. The next web app that needed to be written was in Clojure, and after that almost everything was. What is your talk about?

AM: My talk is broadly about getting the most out of clojure.spec. Specifically it's about interpreting the clojure.spec DSL in order to programmatically understand your specs, and the type and structure of your data.

I introduce some extensions to the DSL so that you can have an even more detailed understanding of how your data is structured. This puts us in a position where we can work out how to automatically transform data between different specs. Who is your talk for?

AM: Anyone who wants to get more out of clojure.spec. What do you hope people will take away from the talk?

AM : That specs are worth writing, and that you can use them to reduce the amount of code you need to write to support different, but similar data structures. What concepts do you recommend people be familiar with to maximize their experience with the talk?

AM: I would hope that the talk is pretty approachable to anyone who's a bit familiar with clojure.spec. It might be good to be familiar with parsing Clojure code into an abstract syntax tree. What resources are available for people who want to study up before the talk?

AM: clojure.spec's rationale is worth a read.

If people want to read up on ASTs, etc., then most compiler books will cover that. I personally liked "Modern Compiler Implementation in ML" by Andrew W. Appel.

Timothy Baldridge gave a good talk about tools.analyzer at Clojure/West 2014.

  • Where can people follow you online?

AM: @andrewmcveigh on twitter and Are there any projects you'd like people to be aware of? How can people help out?

AM: I've extracted much of the work behind this talk into a library, it's called Speculate. It's pretty experimental at the moment, so there's still loads to do. Where do you see the state of Clojure in 10 years?

AM: A Clojure I'd like to see in 10 years would have a self-hosted compiler. It could be compiled to native code. There would be more focus on making the idiomatic solution the optimum solution, and it would have an optional static type system with type inference. If Clojure were an animal, what animal would it be?

AM: O'Reilly says it's a painted snipe, who am I to argue?