4 ms·

> However, some people mistakenly view this as a shortcoming because they believe that the image prevents you from using your favourite programming tools, like

> However, some people mistakenly view this as a shortcoming because they believe that the image prevents you from using your favourite programming tools, like Emacs, GitHub, diff, grep, etc. That’s not actually true. Talk about... I'm about to go Frank Grimes here. Images are bad because you want a visible and complete description of your program, not some image with details squirreled away in nooks and crannies. It's basic engineering to have an exhaustive and explicit description of what your program is doing. Smalltalk's main shortcoming is that it offers nothing useful that other languages lack. And it lacks stuff other languages offer. Other languages let you look at the code and see that certain things cannot happen, while looking at a small fraction of the code. Smalltalk doesn't offer this. That's a serious deficiency.

igouy 7y ago
> Images are bad because Because we lack the wits to archive source-code elsewhere? Save the source-code in files (or some other repository) and when desired build a working image — duplicate the distro image and fileIn your own source-code files (hint: that’s scriptable) — fileOut changes as convenient.
segmondy 7y ago
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?

igouy 7y ago

> Images are bad because Because we lack the wits to archive source-code elsewhere? Save the source-code in files (or some other repository) and when desired build a working image — duplicate the distro image and fileIn your own source-code files (hint: that’s scriptable) — fileOut changes as convenient.

segmondy 7y ago

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?