4 ms·

I feel like a lot of the really clever and elegant things about smalltalk as a language and an object model got bogged down in the program image execution model

I feel like a lot of the really clever and elegant things about smalltalk as a language and an object model got bogged down in the program image execution model, to the point where it stunted the evolution of those ideas for a long time. We're getting to the point where such a model is more practical now, but it still strikes me as hopelessly impractical even so. It wasn't until OSX made Objective-C take off and Rails made Ruby take off that some of the fundamental language features entered the mainstream, and they did so with a gusto that other 'ivory tower' languages wish they could achieve. But only by leaving the image model behind. It seems like something like Erlang managed to do what Smalltalk tries to do with the image better, allowing for easier to reason about deployment, collaboration, and version control while still letting you deal with a system of relatively opaque boxes of replaceable code.

davidw 13y ago
Funny you should mention Erlang, as I think that in its own way, it's treading the lisp/smalltalk path of getting a few things really, really right, and being head and shoulders better for certain kinds of applications. And yet, at the same time, doomed to sooner or later have enough of its goodies ripped off by programming languages that are more mainstream, that will far surpass it in functionality. Go and Scala, for instance, nabbed some of the concurrency stuff, although Go is still missing some of what makes Erlang really distinct.
- discreteevent 13y ago
  Dart is trying to rip off Smalltalk and Erlang while putting on Algol sheep's clothing. I have no doubt they will be successful at the Smalltalk part as most of the team seem to be ex-Smalltalkers or ex-Smalltalk VM'ers. I don't know enough about Erlang to know if Dart isolates approximate it.
bromagosa 13y ago
But only by leaving the image model behind. There are many Smalltalks without an image actually... GNU-Smalltalk, Smalltalk/X and Amber, for instance. GemStone/S uses a mixture between image and filesystem, so it can't be regarded as a traditional image-based system either. The only Smalltalks that still use an image paradigm (that I know of) are Squeak derivatives (Squeak, Pharo, Cuis) and VisualWorks. That said, I believe the image is a very valid model, and I prefer working on a Pharo environment than anywhere else. However powerful text editors, IDEs and debuggers may be, you can never reach the same level of integration between tools and system if your tools, your language and your system are not the exact same thing.
- dfox 13y ago
  Both Gnu Smalltalk and Smalltalk/X are able to use images, while GST is optimized for "normal source code" model, in ST/X it's mostly an artifact of implementation and file system resident source code is simply a way to store what essentially amounts to changes file in classical implementations (the killer feature is that you in most common case can use non-ST specific VCS without significant issues). In all I haven't seen ST implementation with good development tools that is not at least partially image based. The problem I see with ST IDEs is the fact that most advanced features work by introspecting live image state and autogenerating some source code, which completely break any attempts to meaningfully define what is (versionable) programmer-written input and what is derived tool output.
  - bromagosa 13y ago
    True, they're partially image-based. In all I haven't seen ST implementation with good development tools that is not at least partially image based. But what about Amber?
- hboon 13y ago
  Dolphin uses images too.
rahoulb 13y ago
And yet people are talking about using VM images and the likes of Docker for deployment nowadays.
- stormbrew 13y ago
  There is definitely a level where the concept makes a lot of sense, but even with things like docker or vagrant or ec2 images there is still an expectation that you keep around enough information to replicate the image from scratch, be it a shell script or chef or puppet or a dockerfile. Smalltalk's images didn't really have this feature.
  - rahoulb 13y ago
    I was always told to fileout my work and then filein into a blank image to remove any cruft that accumulates during development. That's pretty much the same?
    - hboon 13y ago
      There were 2 camps. I like to do my work with a single image over months, saving code to a native (Smalltalk) version control system. Just doing the occasional testing with a fresh image and loading my code in to verify things are doing fine, as well as when deploying.
      - igouy 13y ago
        There were people who worked with others, and people who didn't :-)
  - igouy 13y ago
    >enough information to replicate the image from scratch... Smalltalk's images didn't really have this feature< Code changes in ST-80 (the Smalltalk made public in 1980) were automatically logged outside the image. There were (at least) 3 files: - the original source code provided with the implementation (.sou) - the replayable log of changes since the sources file was made (.cha) - the compiled bytecode and objects that make up the current state of the program (.im) The most basic approach to re-building was to take the vanilla sources file and vanilla image file provided by the vendor, and "fileIn" the changes you'd made from the change log. And then there were change sets. And later, a fine-grain method-level VCS database. iirc JPMorgan had 4 people employed just as code-librarians to work on code-reuse across their Smalltalk projects.
pjmlp 13y ago
Back in the early 90's Smalltalk was actually starting to be used in the enterprise, but then came Java. We had access to VisualWorks at the university back then. Many developers aren't aware that Eclipse roots are in Visual Age for Smalltalk. Also that Eclipse's workspace concept was an attempt to create a virtual image out of files. Having said this, Smalltalk's image was a problem in the time when VMs weren't that mainstream in the industry. Additionally many of modern image based source control systems weren't available back then.
- igouy 13y ago
  >but then came Java< Yes. >image based source control systems< "Mastering ENVY/Developer" http://books.google.com/books?id=ld6E19QIMo4C http://books.google.com/books?id=ld6E19QIMo4C
  - pjmlp 13y ago
    I never heard of ENVY, thanks for the info. We used VisualWorks around 1995 in the university for a few projects. When I looked again to Smalltalk, Squeak was already around and Monticello was being used.

davidw 13y ago

Funny you should mention Erlang, as I think that in its own way, it's treading the lisp/smalltalk path of getting a few things really, really right, and being head and shoulders better for certain kinds of applications. And yet, at the same time, doomed to sooner or later have enough of its goodies ripped off by programming languages that are more mainstream, that will far surpass it in functionality. Go and Scala, for instance, nabbed some of the concurrency stuff, although Go is still missing some of what makes Erlang really distinct.

discreteevent 13y ago
Dart is trying to rip off Smalltalk and Erlang while putting on Algol sheep's clothing. I have no doubt they will be successful at the Smalltalk part as most of the team seem to be ex-Smalltalkers or ex-Smalltalk VM'ers. I don't know enough about Erlang to know if Dart isolates approximate it.

bromagosa 13y ago

But only by leaving the image model behind. There are many Smalltalks without an image actually... GNU-Smalltalk, Smalltalk/X and Amber, for instance. GemStone/S uses a mixture between image and filesystem, so it can't be regarded as a traditional image-based system either. The only Smalltalks that still use an image paradigm (that I know of) are Squeak derivatives (Squeak, Pharo, Cuis) and VisualWorks. That said, I believe the image is a very valid model, and I prefer working on a Pharo environment than anywhere else. However powerful text editors, IDEs and debuggers may be, you can never reach the same level of integration between tools and system if your tools, your language and your system are not the exact same thing.

dfox 13y ago
Both Gnu Smalltalk and Smalltalk/X are able to use images, while GST is optimized for "normal source code" model, in ST/X it's mostly an artifact of implementation and file system resident source code is simply a way to store what essentially amounts to changes file in classical implementations (the killer feature is that you in most common case can use non-ST specific VCS without significant issues). In all I haven't seen ST implementation with good development tools that is not at least partially image based. The problem I see with ST IDEs is the fact that most advanced features work by introspecting live image state and autogenerating some source code, which completely break any attempts to meaningfully define what is (versionable) programmer-written input and what is derived tool output.
- bromagosa 13y ago
  True, they're partially image-based. In all I haven't seen ST implementation with good development tools that is not at least partially image based. But what about Amber?
hboon 13y ago
Dolphin uses images too.

rahoulb 13y ago

And yet people are talking about using VM images and the likes of Docker for deployment nowadays.

stormbrew 13y ago
There is definitely a level where the concept makes a lot of sense, but even with things like docker or vagrant or ec2 images there is still an expectation that you keep around enough information to replicate the image from scratch, be it a shell script or chef or puppet or a dockerfile. Smalltalk's images didn't really have this feature.
- rahoulb 13y ago
  I was always told to fileout my work and then filein into a blank image to remove any cruft that accumulates during development. That's pretty much the same?
  - hboon 13y ago
    There were 2 camps. I like to do my work with a single image over months, saving code to a native (Smalltalk) version control system. Just doing the occasional testing with a fresh image and loading my code in to verify things are doing fine, as well as when deploying.
    - igouy 13y ago
      There were people who worked with others, and people who didn't :-)
- igouy 13y ago
  >enough information to replicate the image from scratch... Smalltalk's images didn't really have this feature< Code changes in ST-80 (the Smalltalk made public in 1980) were automatically logged outside the image. There were (at least) 3 files: - the original source code provided with the implementation (.sou) - the replayable log of changes since the sources file was made (.cha) - the compiled bytecode and objects that make up the current state of the program (.im) The most basic approach to re-building was to take the vanilla sources file and vanilla image file provided by the vendor, and "fileIn" the changes you'd made from the change log. And then there were change sets. And later, a fine-grain method-level VCS database. iirc JPMorgan had 4 people employed just as code-librarians to work on code-reuse across their Smalltalk projects.

pjmlp 13y ago

Back in the early 90's Smalltalk was actually starting to be used in the enterprise, but then came Java. We had access to VisualWorks at the university back then. Many developers aren't aware that Eclipse roots are in Visual Age for Smalltalk. Also that Eclipse's workspace concept was an attempt to create a virtual image out of files. Having said this, Smalltalk's image was a problem in the time when VMs weren't that mainstream in the industry. Additionally many of modern image based source control systems weren't available back then.

igouy 13y ago
>but then came Java< Yes. >image based source control systems< "Mastering ENVY/Developer" http://books.google.com/books?id=ld6E19QIMo4C http://books.google.com/books?id=ld6E19QIMo4C
- pjmlp 13y ago
  I never heard of ENVY, thanks for the info. We used VisualWorks around 1995 in the university for a few projects. When I looked again to Smalltalk, Squeak was already around and Monticello was being used.