[embedding-shape]

Sure, so once a week or so you need to restart the process if you end up like that.

What I've seen people do, is restart the process after each change like you typically do in other languages, rather than evaluating the current form...

[cfiggers]

The thing that happens to me is that I'll get something working in the REPL, then try to deploy it and it breaks—because unbeknownst to me, I had gotten my REPL into some state where everything was working, but a cold start doesn't look the same.

Is this a skill issue? Absolutely. Do I still restart the REPL frequently (not after every def, but often) just to make sure I'm working with the same environment my program will be experiencing at run time? Yes I absolutely do.

[embedding-shape]

Ah yeah, been there, and probably the first time was when renaming a function but missing to update callers, so callers keep calling the old function, and you have no idea why the changes you made in the new function aren't working.

I have a this little function for clearing the current namespace that I call every time I rename any var inside a namespace:

  (defn clear-ns []
    (map #(ns-unmap *ns* %) (keys (ns-interns *ns*))))

Not a perfect solution, but personally I also don't know a better solution that doesn't involve loosing out on other (non-negotiable for me) benefits.

[Folcon]

Couldn't you have one test that requires your -main and runs it?

Just fire that off every now and then?

Basically the same thing, but you don't lose repl state

[mvc]

Once a week?! Aren't you killing the repl at least to run a full test suite without any stale leftover developer state before deploying?

[embedding-shape]

Full test suites I run before committing essentially, in a separate tab altogether, then the full suite is typically also run in CI before any deploys.