The interactive model is insanely cool. When building a toy game engine a while back (https://github.com/orthecreedence/ghostie) I saved probably half the development time by being able to redefine functions/values while the game was running.
The old way of lisping is to prototype in lisp, then build in a "real" language (c/java). However nowadays the lisp implementations (CCL/SBCL specifically) are fast/advanced enough to the point where you can prototype in lisp, then just use add some type specifiers and boom there's your app. Hell, with ECL you can even embed your lisp program into another one, while still achieving compiled speeds.
Even better you can attach the repl to a remote instance. I had a problem a little while ago that could only be reproduced on the server. I could connect to the repl over ssh and evaluate and modify code directly.
Compare that to a similar problem I had with a C# app we had. For that I had to stick in a load of logging code, check it in then wait half an hour for the CI server to deploy before running and checking the logs.
Do you know if the attaching to a remote instance is available in Racket? I spent some time learning racket a year or two ago, but was under the impression they took out some of the really cool features (or I never discovered them)
Not a racket user, but I'm almost certain that you can do this with Racket. Your editor doesn't care whether your REPL session is local/remote...it just connects to a an address/port. You can set this to be 127.0.0.1 or whatever remote server you want to connect to.
Most REPLs will only accept connections from localhost by default (a sensible idea). In this case you just need to setup an ssh tunnel to the machine and connect through that.
You can get this in other languages too. For example, Flask (a Python web framework) has a fantastic debug-mode error page that totally changed the way that I think about web development. Any time an exception is thrown in a view function (and this includes the exceptions that you idiomatically throw for HTTP 4xx and 5xx errors) the debug-mode error page would have a stack trace (obviously), but also an interactive REPL that could be opened at any stack frame in that trace. It wasn't necessary all that often, but when it was, boy was it a fantastic way to work.
Not quite as automatic, but XDebug with the Codebug client gives you this exact functionality for PHP. Saved me many a headache over the past few years, and makes tracing data flow in a program I don't know as simple as it can be.
What sort of tools are required for this? I'd like to start taking Lisp seriously, but workflow stories like this tend to hinge on using Emacs/SLIME. Is that always the case?
EDIT: I suppose what I'm asking is whether you could elaborate more on what this looks like, in practice.
Basically I have a horizontally split 'screen' session, code in the top and repl in the bottom, and I just ctrl+[c+c] to send paragraphs from the top to the bottom. I don't remember if vim-slime comes with it or if I augmented it, but I also do ctrl+[c+f] to send the current Lisp/Clojure form, ctrl+[c+l] to send the current line... Or just ctrl+a+tab to switch screen windows and type in the REPL directly.
Actually no, I use vim/slimv almost exclusively. I think Sublime2 might also have features that let you "hook into" a remote REPL, but I'm not very familiar. There may be other editors with lisp integration as well, but I'm not sure what they are.
If you do like vim, slimv is a really great option for lisping.
The old way of lisping is to prototype in lisp, then build in a "real" language (c/java). However nowadays the lisp implementations (CCL/SBCL specifically) are fast/advanced enough to the point where you can prototype in lisp, then just use add some type specifiers and boom there's your app. Hell, with ECL you can even embed your lisp program into another one, while still achieving compiled speeds.