Why your REPL experience sucks
srasu.srht.site
Why your REPL experience sucks
1–10 of 58 posts
Re: Why your REPL experience sucks
#2Workspace-based programming environments have always struggled. When I use Jupyter I rerun the whole book pretty frequently. If the book takes 30 seconds to run it is a big annoyance but saves time relative to the randomly irreproducible problems I see other people have. If the book takes 3 hours to run it is a different story.
Re: Why your REPL experience sucks
#3We keep on making fun of php, but it had this problem solved in the 90s. Hit F5 in the browser, get the latest version of your software. No waiting 30s for a rebuild, no stale versions in caches, no headaches.
Re: Why your REPL experience sucks
#4Whenver I use a REPL I'm annoyed I didn't write it as a test, so I get proper import completion and generally tooling support. Finally I usually want to reuse the code or have a regression.
Re: Why your REPL experience sucks
#5Whenver I use a REPL I'm annoyed I didn't write it as a test, so I get proper import completion and generally tooling support. Finally I usually want to reuse the code or have a regression.
I think you're thinking about a different type of "REPL" than what the author is referring to. What you're thinking about is more of a "Programming Shell", a separate window/tab/pane where you enter code and when you're happy, you copy-paste that into your source file.
What the author is talking about is a REPL running in the background while connected to your editor. So most of the time, you're entering code directly into your file, while evaluating snippets in the REPL but you never leave the editor itself.
With that approach, nothing is stopping you from using the REPL to write the tests themselves. In fact, that's what I tend to get the most value from, writing unit tests together with a background REPL, interactively building up the test case until I'm happy, then committing the unit test that has been written in the process.
Re: Why your REPL experience sucks
#6I really only ever encountered this issue when working with ring routes, as in TFA. Love the macro at the end, may start to use it because why not.
Now I want to say this to Clojure beginners: launching Emacs with a very complicated, non optimized, init (3400 lines of custom elisp code I wrote over the years) takes 1.4s on my system. Now launching the app, with two REPLs (one for Clojure on the back-end, one for ClojureScript on the front-end I'm testing) and about 30 dependencies (including figwheel, which is kinda heavy) takes...
16 seconds.
So, from complete scratch, launching Emacs, opening a Clojure source code file, (which btw also triggers the launch of the Clojure LSP server) and then launching the webapp server, two REPLs and loading the main webapp page in a browser takes less than 18 seconds. Well, ok, it's not from complete scratch as source files that haven't been modified do not need to be recompiled, I'll grant that.
It's a 2019 AMD 3700X with 32 GB of RAM and a NVMe M.2 PCIe 3.0 x4 lanes SSD. Not a bad machine but not last gen either (I'm probably swapping it for a 7700X one of these days).
I'm pretty sure the startup time is going to go significantly down when I'll switch to the 7700X.
So even though it's great to not have to restart the app/REPLs it should not be a problem to restart the whole thing.
If your REPLs take two minutes to start, I'd argue there's an issue and it's time to fix that first. Move from lein to deps.edn (which launches one JVM less, which really helps as Clojure startup times on the JVM are slow), buy a faster dev machine. Buy a PCIe SSD. Use chrome/chromium instead of Firefox for testing your webapp (in my experience chrome is simply way faster for anything JavaScript and, oh boy, does ClojureScript generate lots of JS). Etc.
As a sidenote I'd say this specific "ring route not updated" is a variation of the age old issue of cache invalidation.
So basically: I love working at the REPL and keep my REPL(s) opened for a very long time, hot reloading everything (including ClojureScript on the client-side) without needing to restart everything but I don't lose sleep over the fact that I do sometimes relaunch everything for it takes not even 20 seconds.
Re: Why your REPL experience sucks
#7A related question is why would you want to reload the entire file/namespace every time you make a change?
Coming from a Common Lisp background, I am used to evaluating single forms/functions. I would sometimes re-evaluate the entire namespace, but that would be relatively rare.
I switched to Clojure many years ago and followed the same workflow. Then ClojureScript and tools like figwheel came along and I was somewhat surprised to find that people admire the "auto-reload" functionality so much: save a ClojureScript file and all of it gets re-evaluated in the browser interpreter. I found this to be inefficient, somewhat annoying, and a big step back from evaluating exactly what you wanted to.
My guess is that lots of those people never worked with a REPL where you eval single forms from the editor, so this auto-reload on each save seemed much better. But it isn't! And it creates its own problems, like the one the OP solves in the article.
Re: Why your REPL experience sucks
#8A related question is why would you want to reload the entire file/namespace every time you make a change? Coming from a Common Lisp background, I am used to evaluating single forms/functions. I would sometimes re-evaluate the entire namespace, but that would be relatively rare. I switched to Clojure many years ago and followed the same workflow. Then ClojureScript and tools like figwheel came along and I was somewha…
FWIW, I just use C-c C-k with CL because it's easier. The standards lawyer in me also wants to point out that implementations are free to inline function calls that are in the same file as the function definition, but I'm not aware of any implementation that takes advantage of this, so that's rather academic.
Re: Why your REPL experience sucks
#9A related question is why would you want to reload the entire file/namespace every time you make a change? Coming from a Common Lisp background, I am used to evaluating single forms/functions. I would sometimes re-evaluate the entire namespace, but that would be relatively rare. I switched to Clojure many years ago and followed the same workflow. Then ClojureScript and tools like figwheel came along and I was somewha…
No friction is better than friction.
Having to manually reload parts of a file is friction, and introduces possible heisenbugs... e.g. A,B, C were changed, but you forgot to reload A.
There were good reasons for doing it that way when we had 10000x less computing power, but these days? Nah..
Re: Why your REPL experience sucks
#10A related question is why would you want to reload the entire file/namespace every time you make a change? Coming from a Common Lisp background, I am used to evaluating single forms/functions. I would sometimes re-evaluate the entire namespace, but that would be relatively rare. I switched to Clojure many years ago and followed the same workflow. Then ClojureScript and tools like figwheel came along and I was somewha…
Hot reloading is useful when you're making something related to a React-based UI, which you likely are close to 99% of the time in ClojureScript. I seriously doubt it has anything to do with a lack of REPL experience. I use a traditional editor-connected REPL 100% of the time in Clojure and 0% of the time in ClojureScript. I think most of us doing full-stack Clojure work like that.