5 ms·

Nice article. I would just add the smalltalk is not just a language, but a whole environment. If you have the time I encourage you to give image based developme

Nice article. I would just add the smalltalk is not just a language, but a whole environment. If you have the time I encourage you to give image based development a go. It's still the most productive programming environment I have ever used.

Rochus 6y ago
There are notable versions of Smalltalk such as GNU Smalltalk or SOM which are not running in a virtual image, but can be used like normal file based programming languages. Virtual image based systems have some advantages, but even more disadvantages when it comes to deployment and integration. No wonder that the concept did not catch on. Today there are variants of it, e.g. in Dart, to shorten the start-up time.
- bonzini 6y ago
  GNU Smalltalk does run in an image. The main differences are: 1) it's possible and easy to rebuild the image from scratch 2) it's relatively common to reuse the same image and load files into it through the command line, without saving it the image back at the end of every execution. However the image is still there. :)
  - Rochus 6y ago
    Well, there is the Object Memory as defined in the Bluebook, but otherwise it's file based. There are important differences to Smalltalk-80, where even the compiler and the scheduler are part of an "eternal" (i.e. with no unique origin) virtual image.
    - dharmatech 6y ago
      The guy you're replying to is the guy behind GNU Smalltalk.
      - Rochus 6y ago
        So what? I also implemented a couple of Smalltalk VMs, see https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk or https://github.com/rochus-keller/som https://github.com/rochus-keller/som, and I also spent a lot of time with the GNU ST implementation.
        deleted 6y ago
        [deleted]
        andrewflnr 6y ago
        So what? So maybe you should listen to what they say about GNU Smalltalk. They might know a few things.
        Rochus 6y ago
        This is a discussion based on provable facts. Science needs no proof of authority.
    - bonzini 6y ago
      Saying GNU Smalltalk "is not running in a virtual image" is incorrect. For example, GNU Smalltalk does not load the whole standard library from scratch when you start it, the way for example Python does when you "import os". In addition it's perfectly possible (or even common) to load more packages into the image so that any file-based scripts you launch load faster. And even though by default the compiler is written in C, if you load the "Compiler" package then GNU Smalltalk switches on the fly to a parser and bytecode compiler that's written in Smalltalk. If you load the "Debugger" package, exceptions will take you to a gdb-like debugger, with a companion text-based interactive inspector. (The scheduler is part of the image in the same way as in Smalltalk-80, and features such as exception handling and the debugger are entirely implemented in Smalltalk; the only custom feature of the GNU Smalltalk VM that the debugger uses is single-stepping). So even though the image is not as pervasive as in Smalltalk 80 or Pharo (development happens in files and builds upon an image, instead of happening straight in the image), the image is there and it's not just an implementation detail.
      - Rochus 6y ago
        Thanks for the explanation. It's about the wording. The fellow used "whole environment" and "image based development". I used the term "virtual image" from the Bluebook to mean the same. The Bluebook says "Two major components of the Smalltalk-80 system can be distinguished: the virtual image and the virtual machine. 1. The virtual image consists of all of the objects in the system [...]". The important point here is "all of the objects", especially also the compiler. There is no Smalltalk language outside of a Smalltalk-80 virtual image. You cannot do anything in an original Bluebook system without running the virtual image. That's what the fellow referred to by "whole environment" and I by "running in a virtual image". In GNU Smalltalk you don't need to load an image (i.e. persisted Object Memory state) to do anything reasonable. There is a compiler and and interpreter, and being "file based" is known to be a core benefit proposition of GNU Smalltalk, isn't it?
        bonzini 6y ago
        > In GNU Smalltalk you don't need to load an image (i.e. persisted Object Memory state) to do anything reasonable. True but the first thing the VM does if it does not give an image is create empty classes and load files that define those classes. Only then does it do whatever it was asked to do, so the ObjectMemory was not loaded from a persisted state but is effectively indistinguishable from one. Once the image exists, the main difference between the GST file-based approach and the traditional Smalltalk-80 image-based development is that saving the image back is not "saving your work" but "preparing a cache" in which to load source files ephemerally. But that's just an additional possible use of the image that could be implemented in Squeak/Pharo as well, just like GST had class browser for development if you really wanted.
  - sigzero 6y ago
    Is Windows support there now?
    - bonzini 6y ago
      I honestly haven't done any serious work on GNU Smalltalk in the last 10 years, but it should have worked already back then. The GUI used GTK+, but it was still on 2.x.
- igouy 6y ago
  > but even more disadvantages when it comes to deployment and integration. For example? Compared to what?
  - Rochus 6y ago
    > For example Getting rid of objects not belonging to the application to be deployed is difficult or impossible. According to my analysis of the original ST80 v2 virtual image there is a very high interdependency among objects; and since there is no static type information, many dependencies are not statically identifiable. There are also many objects that have not been created or initialized anywhere in the source code (neither in the sources file nor in the Bluebook interpreter), but on which the functionality of the system depends. Versioning of objects and corresponding source code is difficult, also combining a certain version of different components or communication drivers with other parts to be integrated, and so on. > Compared to what? E.g. Java or C++ or any technology with clearly identifiable compilation and configuration units.
    - igouy 6y ago
      > Getting rid of objects not belonging to the application to be deployed is difficult or impossible. 1) So don't get-rid, now where is "the problem"? 2) So only add "belonging to the application" stuff to the base image. > … objects that have not been created or initialized anywhere in the source code … but on which the functionality of the system depends. 3) So those are objects that will always be deployed, now where is "the problem"? > Versioning of objects and corresponding source code is difficult… So application source code isn't just text that can be saved in text files and versioned like other text files, and loaded into a Smalltalk image in a scriptable repeatable build process?
      - Rochus 6y ago
        > So don't get-rid, now where is "the problem"? Well, not every software manufacturer want's to deploy all development tools used to develop the software and possibly code which is only meant to be used inhouse. And if you e.g. deploy to safety-related targets you even have to demonstrate that there is no "dead code" (e.g. DO-178). Of course it doesn't matter for hobby or non-critical applications. > So application source code isn't just text that can be saved in text files and versioned like other text files In ST80 source code is just an external dump file; the actual configuration unit is the virtual image. Bootstrapping a virtual image from source code in ST80 is very difficult or nearly impossible.

Rochus 6y ago

There are notable versions of Smalltalk such as GNU Smalltalk or SOM which are not running in a virtual image, but can be used like normal file based programming languages. Virtual image based systems have some advantages, but even more disadvantages when it comes to deployment and integration. No wonder that the concept did not catch on. Today there are variants of it, e.g. in Dart, to shorten the start-up time.

bonzini 6y ago
GNU Smalltalk does run in an image. The main differences are: 1) it's possible and easy to rebuild the image from scratch 2) it's relatively common to reuse the same image and load files into it through the command line, without saving it the image back at the end of every execution. However the image is still there. :)
- Rochus 6y ago
  Well, there is the Object Memory as defined in the Bluebook, but otherwise it's file based. There are important differences to Smalltalk-80, where even the compiler and the scheduler are part of an "eternal" (i.e. with no unique origin) virtual image.
  - dharmatech 6y ago
    The guy you're replying to is the guy behind GNU Smalltalk.
    - Rochus 6y ago
      So what? I also implemented a couple of Smalltalk VMs, see https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk or https://github.com/rochus-keller/som https://github.com/rochus-keller/som, and I also spent a lot of time with the GNU ST implementation.
      - deleted 6y ago
        [deleted]
      - andrewflnr 6y ago
        So what? So maybe you should listen to what they say about GNU Smalltalk. They might know a few things.
        Rochus 6y ago
        This is a discussion based on provable facts. Science needs no proof of authority.
  - bonzini 6y ago
    Saying GNU Smalltalk "is not running in a virtual image" is incorrect. For example, GNU Smalltalk does not load the whole standard library from scratch when you start it, the way for example Python does when you "import os". In addition it's perfectly possible (or even common) to load more packages into the image so that any file-based scripts you launch load faster. And even though by default the compiler is written in C, if you load the "Compiler" package then GNU Smalltalk switches on the fly to a parser and bytecode compiler that's written in Smalltalk. If you load the "Debugger" package, exceptions will take you to a gdb-like debugger, with a companion text-based interactive inspector. (The scheduler is part of the image in the same way as in Smalltalk-80, and features such as exception handling and the debugger are entirely implemented in Smalltalk; the only custom feature of the GNU Smalltalk VM that the debugger uses is single-stepping). So even though the image is not as pervasive as in Smalltalk 80 or Pharo (development happens in files and builds upon an image, instead of happening straight in the image), the image is there and it's not just an implementation detail.
    - Rochus 6y ago
      Thanks for the explanation. It's about the wording. The fellow used "whole environment" and "image based development". I used the term "virtual image" from the Bluebook to mean the same. The Bluebook says "Two major components of the Smalltalk-80 system can be distinguished: the virtual image and the virtual machine. 1. The virtual image consists of all of the objects in the system [...]". The important point here is "all of the objects", especially also the compiler. There is no Smalltalk language outside of a Smalltalk-80 virtual image. You cannot do anything in an original Bluebook system without running the virtual image. That's what the fellow referred to by "whole environment" and I by "running in a virtual image". In GNU Smalltalk you don't need to load an image (i.e. persisted Object Memory state) to do anything reasonable. There is a compiler and and interpreter, and being "file based" is known to be a core benefit proposition of GNU Smalltalk, isn't it?
      - bonzini 6y ago
        > In GNU Smalltalk you don't need to load an image (i.e. persisted Object Memory state) to do anything reasonable. True but the first thing the VM does if it does not give an image is create empty classes and load files that define those classes. Only then does it do whatever it was asked to do, so the ObjectMemory was not loaded from a persisted state but is effectively indistinguishable from one. Once the image exists, the main difference between the GST file-based approach and the traditional Smalltalk-80 image-based development is that saving the image back is not "saving your work" but "preparing a cache" in which to load source files ephemerally. But that's just an additional possible use of the image that could be implemented in Squeak/Pharo as well, just like GST had class browser for development if you really wanted.
- sigzero 6y ago
  Is Windows support there now?
  - bonzini 6y ago
    I honestly haven't done any serious work on GNU Smalltalk in the last 10 years, but it should have worked already back then. The GUI used GTK+, but it was still on 2.x.
igouy 6y ago
> but even more disadvantages when it comes to deployment and integration. For example? Compared to what?
- Rochus 6y ago
  > For example Getting rid of objects not belonging to the application to be deployed is difficult or impossible. According to my analysis of the original ST80 v2 virtual image there is a very high interdependency among objects; and since there is no static type information, many dependencies are not statically identifiable. There are also many objects that have not been created or initialized anywhere in the source code (neither in the sources file nor in the Bluebook interpreter), but on which the functionality of the system depends. Versioning of objects and corresponding source code is difficult, also combining a certain version of different components or communication drivers with other parts to be integrated, and so on. > Compared to what? E.g. Java or C++ or any technology with clearly identifiable compilation and configuration units.
  - igouy 6y ago
    > Getting rid of objects not belonging to the application to be deployed is difficult or impossible. 1) So don't get-rid, now where is "the problem"? 2) So only add "belonging to the application" stuff to the base image. > … objects that have not been created or initialized anywhere in the source code … but on which the functionality of the system depends. 3) So those are objects that will always be deployed, now where is "the problem"? > Versioning of objects and corresponding source code is difficult… So application source code isn't just text that can be saved in text files and versioned like other text files, and loaded into a Smalltalk image in a scriptable repeatable build process?
    - Rochus 6y ago
      > So don't get-rid, now where is "the problem"? Well, not every software manufacturer want's to deploy all development tools used to develop the software and possibly code which is only meant to be used inhouse. And if you e.g. deploy to safety-related targets you even have to demonstrate that there is no "dead code" (e.g. DO-178). Of course it doesn't matter for hobby or non-critical applications. > So application source code isn't just text that can be saved in text files and versioned like other text files In ST80 source code is just an external dump file; the actual configuration unit is the virtual image. Bootstrapping a virtual image from source code in ST80 is very difficult or nearly impossible.