As stated before, the fundamental disconnect is that you are imagining a world where all subsequent development on your code is done via SLIME and sockets or so

As stated before, the fundamental disconnect is that you are imagining a world where all subsequent development on your code is done via SLIME and sockets or some similar REPL instance. You see this as simple because you wouldn't consider developing without SLIME / sockets in the application, but consider the other side of the coin. If I am a developer who does not use SLIME / socket connections as my default development pattern, my first step to contributing to your codebase is to either (i) convert to this workflow and toolset, or (ii) develop all of the CLI shims you described, including maintaining them as functionality changes. That leaves me between a rock and a hard place, especially if my text editor of choice doesn't have good SLIME support. Also, I do not quite buy the simplicity of the standalone tool conversion; it assumes the relevant functions are naturally well-suited as entry points, including handling malformed inputs, etc., very cleanly. In my experience, many things that make sense at a REPL in a live system need to change dramatically to mature into robust command-line tools. As for deployment, the interactivity I am describing is exactly the linkage you mention, and it really does come down to shipping a development environment as part of the deployment environment. Shipping a binary with a swank server or similar introduces binary size issues, portability issues (you have to ship dependent libraries along with the binary), and some serious security implications. And while this may be the "lisp way", modern languages manage to avoid these issues just fine.