Comment by mrbrowning | Hacker News Reader

Comment by mrbrowning | Hacker News Reader

I really enjoy Clojure. Persistent data structures, core.async, and transducers have all been really pleasant abstractions to work with. I've been writing in it for fun and utility for maybe five years now, and have used it for one mid-scale contracting project, so I hope that that's sufficient background to prevent dismissal of the following as the gripes of a beginner, but: it's so strange to me, for all of the appeals that Clojure makes to an interactive development process involving the REPL and immediate feedback, that a first-class debugging experience on the level of Common Lisp's doesn't seem to be on the roadmap at all. The type of explorative developing you do in that environment, with the ability to drop into the debugger on error, alter the function body and restart the frame with your new code, seems about as far beyond the standard Clojure workflow as REPL-based development is beyond the save-compile-fix cycle of less interactive language ecosystems.

I can deal with the Java stacktraces and the occasional mystery of which concrete class is actually backing IPersistentMap after however many invocations of assoc, but if the experience of writing code is going to be a pillar of the language's sales pitch, why isn't this sort of next-level debugging experience on anyone's radar? The CIDER debugger is nice, but it's not CL nice.

There's a tracing debugger for CIDER (http://bpiel.github.io/sayid/) and Cursive plugin for InteliJ integrates a step debugger (https://www.youtube.com/watch?v=ql77RwhcCK0), but let's agree matching CL's debugger is a tall-order - it's extremely nice and only deals w/ CL, while Clojure, being a hosted language, cannot hide the underlying implementation (interop calls are so common and a big selling point of Clojure in the first place).

You're right, and I ought to have mentioned the difficulty of implementing something like that for Clojure. So maybe the issue is more holistic, which is that it's hard to tell how it's positioned: it's not quite the sort of language that drills as deep as possible into the affordances of being a Lisp, but it's also not quite the sort of language that does everything just well enough, given its investment in, for example, immutable data structures. That doesn't stop me from using it, or presumably anyone else who gets value out of using it, but I sort of idly wonder what the cases are that it's uniquely suited to.

It might not matter: maybe being the obvious right choice for some use case in the abstract isn't that important, and contextual factors re who's doing the work and how they think are just as relevant to choice of language. Still, it seems like we tend to talk about languages now in terms of their most indispensable applications, for better or for worse.

You could say elixir (via erlang) has this kind of debugging flow. Although not automatic, you can have your program run inside a repl and inspect anything you like. There is also an "observer" program that shows you the running system. All the erlang processes, how they are connected, Who's talking to who, memory use, etc...

Reply on news.ycombinator.com