>Regarding Lisp many in the FOSS camp that never experienced commercial Common Lisp IDEs should give a try, the REPL is only the tip of the iceberg.
You've said. However, I am unsure as to whether any Lisp implementation outside of the lisp machine truly allowed for programming inside a live environment, such that there is no distinction between the live environment and the code on disk, where the image IS your environment.
Although being able to serialize your live environment to disk goes a long way. As a schemer, I'm still drooling over that particular feature.
The bigger Lisp IDEs have a different idea. They use the running image as an information system about all the sources it has seen, which means, which it has loaded and/or compiled. Location of source, arguments, who calls who and from where, documentation snippets, ... When you load and compile, this data is continously updated.
It's not as radical as the InterLisp-D system, which is in many ways similar to Smalltalk - when in fact many ideas in Smalltalk are coming from Interlisp and its earlier BBN Lisp, including part of the runtime technology, which enables dumping/restarting images.
'the lisp machine' did not do that. There were different attempts. The MIT Lisp Machine used Lisp code in files, with some tool support.
The Xerox Lisp Machine (different hardware, different Lisp, different OS) used a different approach will full managed source code in the image, with managed files as kind of a way to persist sources.
You've said. However, I am unsure as to whether any Lisp implementation outside of the lisp machine truly allowed for programming inside a live environment, such that there is no distinction between the live environment and the code on disk, where the image IS your environment.
Although being able to serialize your live environment to disk goes a long way. As a schemer, I'm still drooling over that particular feature.