4 ms·

Working with Lisp images: it's horrible when you lose track of what runtime change allows your code to continue working. You typically keep a working compilatio

Working with Lisp images: it's horrible when you lose track of what runtime change allows your code to continue working. You typically keep a working compilation between code and your intended environment, and use the run time to experiment in between changes.

DigitalJack 10y ago
I think this all the time. I have to refresh my clojure repl because I forget what I've eval'd or not and the cognitive load of mentally tracking that state is not something I want to bother with.
- geocar 10y ago
  Clojure is unusually leaky compared to Unix/Linux or (for example) Erlang. If we design systems out of a collection of processes, that we can replace at will, then what we actually have is a collection of checkpoints and branches that we can try simultaneously. Replacing individual branches allows us to try out changes there, without having to rebuild (and wait) the entire system. Another way to think about this, is that Clojure is more like subversion than like git: It might be better than RCS, but you're still stuck with a linear revision history, and new changes can't completely conflict with old objects and old changes that are created. And yet another way, is to imagine all of those old class definitions that old objects hold onto are actually global variables, because they have global (time) extent, and yet are unreachable, so it's difficult to find out whether your new code is being affected by those old settings. Smalltalk, and even other (esp. Commercial) Lisps don't have this problem. It has nothing to do with interactivity, but with hidden state.
jxy 10y ago
This reminds me of one of the good things APL has. You can interactively change anything in your workspace, and all the things (array, function, operators) can be serialized, programmatically within the language.
yaowenjiaozi 10y ago
In Smalltalk implementations like Pharo, Squeak etc changes are captured in a changes file. If the image crashes before being saved, it is possible to cherry pick and replay unsaved changes from the changes file.
- geocar 10y ago
  You can do this with Docker as well: Mount two commits and diff between them, pull bits into a third. It's also a surprisingly convenient way to build tests.

DigitalJack 10y ago

I think this all the time. I have to refresh my clojure repl because I forget what I've eval'd or not and the cognitive load of mentally tracking that state is not something I want to bother with.

geocar 10y ago
Clojure is unusually leaky compared to Unix/Linux or (for example) Erlang. If we design systems out of a collection of processes, that we can replace at will, then what we actually have is a collection of checkpoints and branches that we can try simultaneously. Replacing individual branches allows us to try out changes there, without having to rebuild (and wait) the entire system. Another way to think about this, is that Clojure is more like subversion than like git: It might be better than RCS, but you're still stuck with a linear revision history, and new changes can't completely conflict with old objects and old changes that are created. And yet another way, is to imagine all of those old class definitions that old objects hold onto are actually global variables, because they have global (time) extent, and yet are unreachable, so it's difficult to find out whether your new code is being affected by those old settings. Smalltalk, and even other (esp. Commercial) Lisps don't have this problem. It has nothing to do with interactivity, but with hidden state.

jxy 10y ago

This reminds me of one of the good things APL has. You can interactively change anything in your workspace, and all the things (array, function, operators) can be serialized, programmatically within the language.

yaowenjiaozi 10y ago

In Smalltalk implementations like Pharo, Squeak etc changes are captured in a changes file. If the image crashes before being saved, it is possible to cherry pick and replay unsaved changes from the changes file.

geocar 10y ago
You can do this with Docker as well: Mount two commits and diff between them, pull bits into a third. It's also a surprisingly convenient way to build tests.