4 ms·
What I don't like about building systems at the REPL is that when I investigate a possibility and it works out, I have to identify the code that's actually need
by dkarl 1y ago
What I don't like about building systems at the REPL is that when I investigate a possibility and it works out, I have to identify the code that's actually needed, clean it up, and turn my ad-hoc tests in the REPL into unit tests. There's a trade-off between quick experimentation and the mess I create in search of immediate feedback.
I think an LLM could help with that. Ideally, I could say, "Please add the widget-muckle-frobnicate function from the current REPL session to the codebase. Fix or flag any shortcuts I took in its implementation, such as hardcoding configuration and naming functions 'foo' or 'bar', and add unit tests that include the examples I tried in the REPL as well as property-based tests to exercise edge cases."
- diggan 1y ago> Please add the widget-muckle-frobnicate function from the current REPL session to the codebase. I think this is your problem, those two things should be the same, not two different things. When I'm working with a Clojure REPL, I write down code in a .clj file, then evaluate that code via the REPL but without leaving my editor. "Moving" something from a REPL session to the codebase is a matter of saving the current file you're editing. I wrote more about the exact process I typically use when going from "prototyping with a repl, to having a test case" (https://news.ycombinator.com/item?id=44106445 https://news.ycombinator.com/item?id=44106445) and it's essentially changing "comment" to "deftest" then saving the file again, now it's a unit test. I do find value from LLMs in general, but I don't see much value in taking a process that takes a minute or less and trying to make LLMs do it.
- sokoloff 1y agoExactly (on the first two paragraphs). I (almost) never type anything into the REPL window itself. I might type a "5" and evaluate it just to see if the REPL is busy or not, but otherwise, everything the REPL evaluates comes from an emacs source code buffer, sent via CIDER to the REPL. At most, it might be in a "Rich comment" and thus not evaluated next time I load that file, but those tend to be small, interactive tests and not defns. Unless emacs crashes with the buffer unsaved, there's nothing the REPL has that the source file doesn't.
- dkarl 1y agoI usually have a buffer that is kind of like a Jupyter notebook, and it accumulates a lot of stuff that may or may not turn out to be useful in the end. If I'm doing the work to keep things tidy as I go, so it's close to production ready at the end, then it isn't much different from traditional programming. It ends up just being TDD in one file instead of two.