PRE-WEST INTERVIEW: COLIN FLEMING
Talk: Debugging Clojure code with Cursive
Colin Fleming's talk at Clojure/West is about debugging Clojure in Cursive.
Background
Colin Fleming is the developer behind Cursive. Cursive is the #2 most popular Clojure IDE (behind Emacs and just ahead of vim). It is based on IntelliJ, and so has a lot of useful JVM features. This talk will focus on debugging and also how the JVM debuggers fare with functional code.
For a great introduction to Cursive, see Colin Fleming's talk at Clojure/conj last year.
About Colin Fleming
Introduction
Colin Fleming generously agreed to do an interview about his talk at Clojure/West. The background to the talk is available, if you like.
Interview
PF.tv: How did you get into Clojure?
Colin Fleming: Several years ago I was working in Java on online transaction processing systems. I was interested in the promise that Clojure had to make such systems easier to work with, in particular the concurrency aspects. I also liked Clojure philosophically, a lot of the ideas behind it really resonated with me.
I really wanted to use IntelliJ since I use it all the time and love it, but the existing plugin for it was fairly immature. I ended up porting a lot of it from Java to Clojure and that became Cursive, which is still the main Clojure project I've worked on.
PF.tv: This year you're talking about debugging in Cursive. I never run an interactive debugger in Clojure, mostly because I don't have one readily available. I do remember using one in Java all the time. What am I missing?
CF: I use the debugger in Cursive pretty much every day, probably in a similar way to which you used to in Java. Cursive's debugger is basically IntelliJ's JVM debugger so it works in very much the same way with some Clojure-specific extensions. So you can stop at breakpoints, step, evaluate Clojure expressions, have conditional breakpoints where the conditions are Clojure expressions and all that. I'm working on some more Clojure-specific functionality like having a REPL running when stopped at a breakpoint too, which I think will be pretty nice. That said, the current expression evaluation works pretty well, and you can interactively inspect the returned objects and so on.
An argument I hear a lot is that a debugger is not required when you have a REPL, since you can interactively test parts of your application more easily. I think it's definitely the case that the REPL allows some of the exploration of a live system that previously required a debugger, but I've never understood why you wouldn't want both. All my work is on Cursive, where I'm integrating with a massive framework that I don't understand well, it's written in Java and is totally stateful so it's actually pretty tough to test at a REPL like that sometimes. The debugger is critical to being able to see what the framework is doing, working without it would be much harder than it is.
PF.tv: Is the debugger ready for prime time? If not, what is left?
CF: Yes, definitely - it's all working pretty well now. That said, nothing is ever totally done, I still have improvements I'd like to make to it. Performance is sometimes an issue, because the JDI really likes you to know the exact name of the class you're working with. That's basically impossible to predict from source code in Clojure so you end up having to filter through a lot of classes. I hope to be able to improve that somewhat. Recent versions of IntelliJ also added functionality which displays the results of evaluated expressions right in the editor while debugging, similar to Light Table's inline REPL evaluation. Cursive doesn't support that for Clojure code yet, but I'll fix that soon. And a fair amount of Java leaks through in the UI since it's based on IntelliJ's Java debugger - variables are displayed with their mangled names, and so on. JetBrains are actually in the process of migrating their Java debugger from an old proprietary framework to a new language-agnostic one that they use to develop debuggers for other languages. Once that's complete hopefully I can tidy that up.
PF.tv: You're really making me want to jump into Cursive. I used to use the debugger all the time. Basically, I'd write code unsure of what it would do, and just jump in and see. That was in Java, so there was still a long compile step. Is that better in Cursive since it's an interactive compiler?
CF: Sure, using Cursive you can debug an arbitrary script which will just have the standard Clojure script startup time, or even better you can debug a REPL session. This means that you can put breakpoints in your code, and when that code is hit by whatever you're executing in your REPL it'll stop. I use this a lot when running tests and trying to figure out why a particular test isn't working. Cursive takes care of disabling locals clearing when running like this, and there's also a toggle button in the REPL toolbar for it which you can use when connecting to a remote JVM.
PF.tv: Where can people follow you online?
CF: The best way to get updates about Cursive is on Twitter or on the mailing list. I also have a personal Twitter handle, but that mostly serves to collect fans of the Scottish tennis player. They must be quite confused by my occasional tweets.
PF.tv: If Clojure were a food, what food would it be?
CF: I'm going to go with blue cheese. It's a taste that you have to acquire, but once you do there's nothing better!
