4 ms·

I also go without restaring the repl for weeks, but there are plenty of situations where you need to restart the repl: adding libraries, servers binding to port

by synthc 5y ago

I also go without restaring the repl for weeks, but there are plenty of situations where you need to restart the repl: adding libraries, servers binding to ports, making sure you have no temporary edits, etc, etc. The whole 'reloaded workflow' is a workaround to the slow restart IMGO. It works well, but there is a learning curve, especially coming from languages with fast edit-compile-run cycles such as go. I've also worked with scheme, and having a repl up and running in milliseconds is really nice.

capableweb 5y ago
> I also go without restaring the repl for weeks, but there are plenty of situations where you need to restart the repl: adding libraries, servers binding to ports, making sure you have no temporary edits, etc, etc. True that temporary edits could in theory get in the way, although I never had that happen to me in ~6 years of experience with Clojure. Server bindings to port should not warrant a REPL restart, usually you can save the returned function/data from starting the server to also turn it off (and unbind the sockets). > The whole 'reloaded workflow' is a workaround to the slow restart IMGO I disagree with this, it's not a workaround. It's a different workflow, yes, but it is different on purpose, not by accident. Being able to evaluate and run snippets of code will (for me) always be a faster workflow than even the fastest edit-compile-run languages, since I can evaluate code in the middle of functions and won't have to have any unit tests just to test something temporarily in isolation.