-
I just finished reading your blog post: https://oli.me.uk/exploring-repl-tooling-with-prepl/ and then went to checkout Conjure, and was surprised that the documentation now mentions Conjure uses nRepl for Clojure, Clojurescript, Babashka and even shadow-cljs. I feel that deserves a follow up blog posts haha Anyways, I'm very curious, was there too many pain points in the end with Prepl? Would you advise against it now for other tools authors? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
So the TL;DR last time I wrote all of this down was essentially: prepl is hyper minimal and good when you need a simple thing that lets you automate sending code from one program to another. It falls down when you try to do anything interesting from a user experience and developer tool standpoint. I spent a couple of years getting it powerful enough to work with and it still massively lacked features that nREPL has as standard as well as didn't really work at all for ClojureScript. I would've had to spend more years rewriting it and essentially reimplementing nREPL (which at the time, I didn't like because I thought it was system that broke all the time when it updated (this wasn't actually true)). So eventually I gave in, I tried supporting nREPL in my next rewrite and everything worked beautifully. All aspects of Clojure were supported, I could provide far more developer tools for users with far less effort. I'm even going to integrate a debugger over the next few weeks which would never have been possible with prepl (well, maybe it would, but it'd be REALLY hard). prepl solves the problem of connecting a simple CLI REPL or program to a remote Clojure program so you can send some code at it. nREPL, more specifically nREPL+CIDER, solves actual day to day developer experience challenges. We get to lean on the collective effort of the entire Clojure tool developer community. prepl was just me on my own trying my best to even match up one eval response to another and doing weird hacks to get some sort of autocompletion to work. Since Conjure's design is so much better these days I can actually add support for prepl but as an opt in system, Conjure supports many languages and many transports. So there's nothing (other than time and effort) stopping me from implementing I just recommend people use nREPL for anything a human needs to do. I'd recommend prepl when you need a machine to talk to a machine (which is very rare and only really useful in simple dev tool areas I think). I hope this sort of answers it. I've answered this a few times and I remember writing all of this up somewhere but I can't find it, I guess this will have to serve as the answer now! Maybe it was a twitter thread from a few years back... if so I'll never find that. |
Beta Was this translation helpful? Give feedback.
-
I came across this. I switched from conjure to using clojure-lsp exclusively but has been looking for a way to send code to a Clojure REPL. @leafgarland, did you get any further along a prepl + clojure-lsp setup? |
Beta Was this translation helpful? Give feedback.
-
@Quantisan I had a "working" prepl but with only a simple EDN parser. I was hoping to make it a streaming parser to cope with larger messages but didn't find the time. |
Beta Was this translation helpful? Give feedback.
So the TL;DR last time I wrote all of this down was essentially: prepl is hyper minimal and good when you need a simple thing that lets you automate sending code from one program to another.
It falls down when you try to do anything interesting from a user experience and developer tool standpoint. I spent a couple of years getting it powerful enough to work with and it still massively lacked features that nREPL has as standard as well as didn't really work at all for ClojureScript. I would've had to spend more years rewriting it and essentially reimplementing nREPL (which at the time, I didn't like because I thought it was system that broke all the time when it updated (this wasn't actual…