5 ms·

I've always found the 'image' environment to be far more interesting than the language of Smalltalk itself. If you do find just code snippets, you're missing o

I've always found the 'image' environment to be far more interesting than the language of Smalltalk itself. If you do find just code snippets, you're missing out on what I, at least, see as the most significant feature of the whole thing. The way it goes about defining the code is clunky, but the overall structure of 'images' and the workflow involved with them is fascinating. I could easily see something similar being the future of containerization when implemented in some other language.

jhbadger 9y ago
Lots of other languages work/worked that way. System images were a common feature of many Lisp systems and some Forth systems in the 1980s.
- agumonkey 9y ago
  Also self
  - deleted 9y ago
    [deleted]
- throwaway7645 9y ago
  The image is just one reason why compiling an SBCL executable results in such a large file. It has state as well...or so I've read.
  - deleted 9y ago
    [deleted]
  - flavio81 9y ago
    When you load Lisp files, they get compiled; this compilation is saved as binary files (often, "fast load files"), that do what it says on the tin: They allow you to, next time, load your program really quickly. Now, your program also has state. If you want, you can also save the state of the program (i.e. by using the "save-lisp-and-die" command). This can create large files, because this allows you not only to quickly "run" the program again, but to also run it with the same state that it had when you did the save.
    - throwaway7645 9y ago
      Thanks for clarifying my comment with actual experience. Much appreciated!
      - flavio81 9y ago
        You're welcome! Forgot to mention, the other reason executable files (if produced) get big, is that compilation of a Lisp program not only produces the machine language form of your program, but it also includes a Lisp runtime. The runtime makes possible having the condition-restart system, and the full power of macros (your program can compile lisp code at runtime if needed, thanks to the runtime.)
theamk 9y ago
That image environment sounds scary to me. I used to do a lot of hardware development, and what I love most about software is that you can always restart from the clean plate (by restarting the program) and/or undo your previous work (with version control). From what I understand, none of this applies to Smalltalk. You always modify code on the fly, so you may end up with properties which exists, but no current code ever sets them. Or your program ends up in the invalid state, and you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete?
- igouy 9y ago
  Simply a) keep a copy of the original image [clean slate] b) keep a copy of your changes/additions [use version control if you like] c) import b into a. Repeat daily or weekly as you please. > You always modify code on the fly Since back in the '70s when Smalltalk was being created at Xerox PARC and used there for experimental systems development, changes were automagically recorded in a changes .cha text file. For more information on the primitive techniques from back in those days see -- "Managing the Evolution of Smalltalk-80 Systems" in Smalltalk-80: Bits of History, Words of Advice http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOfHistory.pdf http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOf...
  - otabdeveloper1 9y ago
    > Simply a) keep a copy of the original image [clean slate] b) keep a copy of your changes/additions [version control] c) import b into a. Really? So we're back to "MyImage.img.bak.2.old.works", "MyImage.img.bak.3.works", "MyImage.img.bak.2.test"? Now that is an experience I do not want to ever have to experience again.
    - igouy 9y ago
      > So we're back to… No, that's a bizarre suggestion you just invented, it has nothing to do with what I wrote.
    - vajrabum 9y ago
zerr 9y ago
Opposite feeling here - mutable/persistent images kept me away from Smalltalk.
- igouy 9y ago
  Because you have had experience with them, or because you haven't had experience with them?
TeddyDD 9y ago
I fell opposite: I appreciate simplicity of Smalltalk syntax, but I prefer environment bases of files

jhbadger 9y ago

Lots of other languages work/worked that way. System images were a common feature of many Lisp systems and some Forth systems in the 1980s.

agumonkey 9y ago
Also self
- deleted 9y ago
  [deleted]
throwaway7645 9y ago
The image is just one reason why compiling an SBCL executable results in such a large file. It has state as well...or so I've read.
- deleted 9y ago
  [deleted]
- flavio81 9y ago
  When you load Lisp files, they get compiled; this compilation is saved as binary files (often, "fast load files"), that do what it says on the tin: They allow you to, next time, load your program really quickly. Now, your program also has state. If you want, you can also save the state of the program (i.e. by using the "save-lisp-and-die" command). This can create large files, because this allows you not only to quickly "run" the program again, but to also run it with the same state that it had when you did the save.
  - throwaway7645 9y ago
    Thanks for clarifying my comment with actual experience. Much appreciated!
    - flavio81 9y ago
      You're welcome! Forgot to mention, the other reason executable files (if produced) get big, is that compilation of a Lisp program not only produces the machine language form of your program, but it also includes a Lisp runtime. The runtime makes possible having the condition-restart system, and the full power of macros (your program can compile lisp code at runtime if needed, thanks to the runtime.)

theamk 9y ago

That image environment sounds scary to me. I used to do a lot of hardware development, and what I love most about software is that you can always restart from the clean plate (by restarting the program) and/or undo your previous work (with version control). From what I understand, none of this applies to Smalltalk. You always modify code on the fly, so you may end up with properties which exists, but no current code ever sets them. Or your program ends up in the invalid state, and you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete?

igouy 9y ago
Simply a) keep a copy of the original image [clean slate] b) keep a copy of your changes/additions [use version control if you like] c) import b into a. Repeat daily or weekly as you please. > You always modify code on the fly Since back in the '70s when Smalltalk was being created at Xerox PARC and used there for experimental systems development, changes were automagically recorded in a changes .cha text file. For more information on the primitive techniques from back in those days see -- "Managing the Evolution of Smalltalk-80 Systems" in Smalltalk-80: Bits of History, Words of Advice http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOfHistory.pdf http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOf...
- otabdeveloper1 9y ago
  > Simply a) keep a copy of the original image [clean slate] b) keep a copy of your changes/additions [version control] c) import b into a. Really? So we're back to "MyImage.img.bak.2.old.works", "MyImage.img.bak.3.works", "MyImage.img.bak.2.test"? Now that is an experience I do not want to ever have to experience again.
  - igouy 9y ago
    > So we're back to… No, that's a bizarre suggestion you just invented, it has nothing to do with what I wrote.
  - vajrabum 9y ago

zerr 9y ago

Opposite feeling here - mutable/persistent images kept me away from Smalltalk.

igouy 9y ago
Because you have had experience with them, or because you haven't had experience with them?

TeddyDD 9y ago

I fell opposite: I appreciate simplicity of Smalltalk syntax, but I prefer environment bases of files