4 ms·

I'm not a fan of the image thing as well, but I suspect it's just a learned behavior. Most of us view code like a book, something to be ready in an orderly fas

I'm not a fan of the image thing as well, but I suspect it's just a learned behavior. Most of us view code like a book, something to be ready in an orderly fashion. But if you view it like a sculpture, an image is like one. You start with a big block of wood, ice, stone and start chipping away and shaping it into what you wish, anytime you come back to it, you have that same exact block with all the things you have done to it.

SamReidHughes 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, 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
> Most of us view code like a book, something to be ready in an orderly fashion. Do authors write books sequentially, first-chapter to last? Is code used sequentially, only in the same order those procedures are defined in a text-file? Does the text-file order of procedure definitions help us understand the call sequence?

SamReidHughes 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, 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

> Most of us view code like a book, something to be ready in an orderly fashion. Do authors write books sequentially, first-chapter to last? Is code used sequentially, only in the same order those procedures are defined in a text-file? Does the text-file order of procedure definitions help us understand the call sequence?