3 ms·

When developing in Emacs Lisp, and other Lisp environments (well, Racket, I guess), you’re editing a file meant to run at startup but can evaluate the code on t

When developing in Emacs Lisp, and other Lisp environments (well, Racket, I guess), you’re editing a file meant to run at startup but can evaluate the code on the fly. So, you have control over how the source is textually written and organized, but can run your UI and see how things get affected by your changes immediately. That’s nice when writing UI code, since you get a tight REPL experience, and lots of little changes to make and try out, without having to restart your program, navigate to the screen, etc. But also, there is a clean separation between your permanent code and your temporary changes. There’s no fileOut business, and no downside. The proper form of your analogy is that you want to chip away at your code, not at a runtime image. The REPL is the advantage here (in Smalltalk), not the fact that there is an image.

igouy 7y ago
When developing in Smalltalk, you're editing class definitions and method definitions meant to run sometime in the future but can evaluate the class definitions and method definitions on the fly. … But also, there is a clean separation between your permanent code and your temporary changes. … The proper form of your analogy is that you want to chip away at your code, not at text scattered among files. The lively computation is the advantage here (in Smalltalk), not the fact that there is an image. The image just makes the lively computation persistent.
sedachv 7y ago
> When developing in Emacs Lisp, and other Lisp environments (well, Racket, I guess), you’re editing a file meant to run at startup but can evaluate the code on the fly. So, you have control over how the source is textually written and organized Interlisp did not work like that; editing took place on in-memory lists and the definitions would be serialized into files on request, which were sort of treated like mini databases. Image-based development was used a lot on Symbolics machines, there are advantages to it over always loading from flat text files.

igouy 7y ago

When developing in Smalltalk, you're editing class definitions and method definitions meant to run sometime in the future but can evaluate the class definitions and method definitions on the fly. … But also, there is a clean separation between your permanent code and your temporary changes. … The proper form of your analogy is that you want to chip away at your code, not at text scattered among files. The lively computation is the advantage here (in Smalltalk), not the fact that there is an image. The image just makes the lively computation persistent.

sedachv 7y ago

> When developing in Emacs Lisp, and other Lisp environments (well, Racket, I guess), you’re editing a file meant to run at startup but can evaluate the code on the fly. So, you have control over how the source is textually written and organized Interlisp did not work like that; editing took place on in-memory lists and the definitions would be serialized into files on request, which were sort of treated like mini databases. Image-based development was used a lot on Symbolics machines, there are advantages to it over always loading from flat text files.