tldr; Which editor-connected REPL setups only require the Clojure CLI tool?
I’m working on putting together something for Clojure(Script) beginners with the help of @eric-normand. I’m not sure what it will end up being exactly – it may take a few forms (blog, GitHub project, video tutorials).
I’m stuck on finding a quick, easy, and widely appealing editor-connected REPL setup .
I’m looking for something that only requires the user to have the Clojure CLI tool i.e. no leiningen or boot.
Main problems I’ve run into so far:
Atom integrations, namely proto-repl, require lein or boot to run and connect to a REPL.
VSCode has no editor connected REPL integration.
Other considerations/concerns:
IntelliJ is ~500mb download (Atom is ~100) and Cursive may require leiningen (not sure)
Text editors like Emacs and Spacemacs have great integrations but prevent devs not accustomed to them from feeling productive quickly
Command-line interfaces like rebel-readline are great but don’t provide paren management or the same experience as evaluating code under your cursor in a file.
I’ve no experience writing plugins and little spare time. Most of us are up to our neck in projects. So I’m trying to rely on existing solutions that may not be perfect but are still really good.
Full disclosure: I use Cursive and IntelliJ with vim mode and Parinfer.
Thanks! Do you have leiningen or boot installed? I think proto-repl uses leiningen or boot under the covers to run the nREPL client. Hopefully not but that’s what I thought…
Well, it is made of software, so the existence of bugs would be unsurprising. That said, we’re actively working on it, and if you’d like to have such a tool that’s less buggy, consider filing issues when you have problems.
I’ve been considering the same problem, and the answer I’ve come to is that we have to accept a federated solution. People will dip their toes in the water a variety of ways, and as their relationship with Clojure becomes more serious they will move to a variety of editors. The complexity in editor-integrated REPLs seems to be either sufficiently great or sufficiently necessary that a single solution is not viable. The community has to work on improving the on-ramp for all of them.
In this landscape I think a toolbox approach is necessary: we provide folks with a variety of low-friction ways to try Clojure (clj and cljs.main, maria.cloud, etc), and for the next step we provide a short list of editors and tools that require work to mind-meld with but that will reward the investment they put in. My list for those editors is emacs (often spacemacs) and Cursive, plus things like rebel-readline.
This aporoach also suggests that as a community, anything we can do to simplify and explain the process of establishing a good workflow in those tools is critical. That means I’m enthusiastic for screencasts, GIFs, and guides for the editor-integrated REPL workflow in those tools, as well as alternative REPL projects like prepl and spiral. Work on these projects is nontrivial and should not be underestimated: it requires effort over months, and usually collaboration, so we should prefer existing solutions as long as they are on a firm engineering foundation.
Sure. Inevitably there will be a federated solution, and I think what we currently have is pretty much that. We might want to be mindful of unintended side-effects to that approach though. Zach Tellman spoke to this a bit in the latest defn podcast (around 1:25:13):
I think it’s something that comes from the top in some respects inasmuch as no one is really willing to come in and say “If you don’t have a really good reason to do this differently, just do it this way.” And those defaults matter. They’re absolutely something that would help the community grow because they would allow people who are coming in to accomplish something. Not just kind of go and float in the void with all these little orbs around them, wondering what they’re supposed to do with all of them. It would actually allow them to get somewhere. And I think that the mean time to accomplishing something substantive in a language is an enormous predictor of whether or not people stick around.
[…]
There’s not a conversation of if we want people to feel great, if they want to feel powerful using Clojure, what are the 10 starter projects that they can work on that will make them feel really awesome.
Giving newcomers a clear and clean path to get into an editor with a connected REPL and paren management positions them to accomplish “something substantive” and feel good doing it. They can load up a starter project and start hacking the same as us. If they have a good time with that, then it’s natural they’d look around at other options (can I write Clojure(script) in my preferred editor? are there interactive tutorials that can help me level up on the language?) and luckily they can find a lot of solutions there.
Totally agreed! It sounds like we’re all working on the situation Bruce Hauman describes:
When I refer to a fluid interactive programming workflow in Clojure I am thinking mainly of inline-eval. Most programmers do not have an experience of what inline-eval is. They have nothing to compare it to. They have not used LISPs and SEXPs. You can describe inline eval and demonstrate it to them until you’re blue in the face and they won’t get it.
It is not until a programmer actually experiences inline-eval as a programming tool that the light goes on. SEXPs start to make more sense, and the why of LISP starts to dawn.
I’m just saying that under a federated ecosystem of editors, we have to provide paths (plural), not one “clear and clean path”. That means my answer to your original question about “finding a quick, easy, and widely appealing editor-connected REPL setup” is that there is none; we’re stuck with all of them and should therefore install lights and signage on each path to editor/REPL integration for custom emacs, Spacemacs, Cursive, and anything else we think should be used. (I see @plexus’ Clojure Mayonnaise article as a meta-guide for which topics to cover in such “highway improvement” projects.)
My current efforts on this front are focused on maria.cloud and community discussion, but I have hope that someone with screencast skills starts doing emacs-rocks-style screencasts of what editor-integrated REPL workflows feel like. Parens of the Dead does a good job at the opposite end of the spectrum, with longer, higher-level screencasts. I think there’s still space in the ~90-second end of that spectrum, and for written guides that hold the new user’s hand more.
This is a very timely thread! I had heard CIDER recently added support for deps.edn-based projects and I was just starting to evaluate going back to Emacs (after two years of using Atom/ProtoREPL), so I am pleased I can stay with Atom, now that Pull Request has been merged in. It still needs some polish: either -Sdeps auto-injection of proto-repl and tools.nrepl or a way to specify additional command-line arguments for clj (like you can for Leiningen, Boot, or Gradle), but it is workable.
What I’ve been using so far is having the following as my ~/.clojure/deps.edn file: https://github.com/seancorfield/dot-clojure/blob/master/deps.edn and then using clj -A:nrepl:proto to start an nREPL server with ProtoREPL loaded, and then connect from Atom. A similar approach could be used for CIDER-enabled nREPL servers (with -A:nrepl:cider and the appropriate alias for CIDER dependencies).
I am not sure what is meant by editor connected REPL integration. But I recently published an extension to VS Code that has some kind of REPL integration. I call it Calva, because it is made from Cider (and nrepl). It supports inline eval, running namespace tests, navigate to definitions, peek at definitions, auto completions and some more. A feature is that it lets you easily switch between backing clic files with the cli or the cljs repl.
It also starts repls in VS Code’s integrated terminals and lets you load the current namespace there and can send code there for evaluation. These repls are a bit clunky compared to Emacs Cider, but it’s a start.
At current Calva does not try to start the nRepl environment, but rather connects to an existing one. It makes it a two step process for jacking in, but makes it easier to keep it somewhat tool agnostic. (I added support for shadow-cljs today.)
I tried with Clojure CLI/deps.edn and it works with that too, at least the Clojure part. I couldn’t figure out how to make Figwheel work in that environment yet.
Full disclosure: I’m in a bit over my head with this project because I am pretty new to the Clojure world. Emacs Cider is wonderful, but a bit too heavy for my Macbook. I probably should have turned to VIM Fireplace, but fell in love with VS Code. Anyway, I would be happy to learn what you think about Calva in respect to how it could support beginners.
For me that is definitely the case. VS Code starts really fast and is always snappy on my machine (a 12 inch Macbook w/ 8 gig RAM). Emacs not so smooth and also impacted the rest of my computer much more. Could have been a configuration issue, of course. Your milage may wary.
