[pjmlp]

REPLs are not ephemeral on Common Lisp environments.

There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind.

On Mesa/Cedar's paper they refer that they wanted to provide the same experience as their Smalltalk and Interlisp-D environments.

On Oberon's case, it required just recompiling/reloading a specific module, which given Oberon's compile speed, was pretty quick.

.NET has now a REPL, which coupled with Edit-and-Continue (when it works) is also quite good.

I used to use Jython/Groovy as my Java REPL, now just have to wait for the Java 9 release.

[agentgt]

> REPLs are not ephemeral on Common Lisp environments.

You'll have to patiently elaborate more for me. Do you mean because the editors keep track of it and that you are working with immutable/idempotent stuff? Otherwise IMO it is ephemeral because you are mutating things and you can forget what you have loaded and what not. I'm probably wrong though.

> There are/were true REPLs with static languages, Mesa/Cedar and Oberon are two examples that come to mind.

Yes many do including my favorite of OCaml's utop but not many allow hot code replacement for a currently running program. I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out.

> I used to use Jython/Groovy as my Java REPL, now just have to wait for the Java 9 release.

I used Groovy as well but mainly because I didn't want to load a full IDE to test a couple of things. As I mentioned before I think with Eclipse/IntelliJ + JRebel + Debug attachment you can get damn close to a REPL.

And depending on how you define REPL I think hot code replacement + debugger might actually be more powerful than a REPL but I have to explore that thought some more.

[pjmlp]

> You'll have to patiently elaborate more for me.

They are image based, so you can just save your session and continue using it later in another day.

> I think the author alluded to that. Of course I have no experience with Mesa/Cedar Oberon. I'll have to check those out.

On those systems, the unit of loaded code is a module and the whole OS only has dynamic libraries as executables.

So you can just reload a module and the next time you do module.proc on the repl, you will be referring to the newly loaded module.

For me an ideal REPL should be like the experience I used to have in Smalltalk.

[agentgt]

Yes I agree on the Smalltalk point. I think Squeak was at one point the very future of REPL-like development and hence why I think the article doesn't really go into how REPLs could be better and how they aren't really that much better than other development tools (ie IDE + debugger,... I mention this in other comments).

I had no idea that common lisp had image saving! I only used the Carnegie Mellon one in college.... its been a long time.

[lispm]

> I had no idea that common lisp had image saving!

Lisp has image saving since around 1960...

[agentgt]

I probably did at one point know this as I did use it in college but for some reason forgot it (we are talking 15 plus years) given that is apparently how you distribute executable lisp code... IIRC though I hated image saving when it came to Squeak aka Smalltalk so I'm not sure if I did like that.

[lispm]

> given that is apparently how you distribute executable lisp code

LispWorks can:

* save images

* create optimized images/applications for delivery, using a treeshaker for removing unused stuff

* can generate Mac applications with the usual ceremony/ application bundles

* can generate shared libraries which can be linked into programs written in C or similar

Some other compilers can generate standalone C code doing whole-program compilation. For example mocl or some inhouse compilers used by companies.