Hacker News Reader

Comment by _mhr_ | Hacker News Reader

Slightly OT, but when you edit code in the REPL this way using conditions/restarts, how do you avoid getting your code out of sync with the REPL's state? It seems with a long-running REPL, you eventually run into:

- Out of order execution means we don't know what order our code should be run in to achieve the current state

- If we run some code in the REPL and never save it in a file, then our state is also out of sync

- Finally, if we redefine some code, there's no way the state can be in sync with the code if started from the beginning

How do Common Lispers typically deal with these issues for a REPL that's been running for days or weeks, short of just saving the image and never turning it off?

View on HN

As the cousin comment stated, we use sources. Even with this condition/restarts/debugger: fix the error in the source and recompile it, not in the REPL.

And we have the right to restart the image. For example, I run the tests from the terminal, hence from scratch, from time to time, typically before pushing my commits. I have a CI that tests and builds the program. I deploy a static build. We don't use images coming from development here. However, I can connect to a running image in prod and tweak settings if I want, or just look around[]. I could very easily change the code, but I'll do that in my sources and do a clean deploy. Or not. I too heard about people who mold a running image for years, their sources totally out of sync O_o

[]: there's a trading startup that posts screenshots of their Sly REPL from prod, that's where they ask their system for data. They didn't have to setup another complex layer just to see data from prod.

This is true of any image based development, as well. You can get the same thing in Java with hotswapping code, even.

That is to say, this is a bit of a concern, but isn't typically as large of one as you'd think. There are plenty of ways to make it so that you can't reason about a program. In general, you avoid doing those things.

Specifically to your question, I think, the biggest trick is that you rarely use the REPL as where you type your code. For that, you typically still use files and eval the file into the environment controlled by a repl. Even in emacs, you rarely just execute elisp from the scratch buffer. Unless you know it is something you don't care to keep, of course. Instead, you are working with files and evaluate the file on a regular basis.

repl should have a session back patch feature

whatever you typed, extract a patch and send it up to your editor for faster reconciliation

Reply on news.ycombinator.com