4 ms·

That seems to be the common complaint about image bases systems like Smalltalk and (some versions of) Common Lisp. The difficulty of collaborating, auditing, d

That seems to be the common complaint about image bases systems like Smalltalk and (some versions of) Common Lisp. The difficulty of collaborating, auditing, deploying, continuous integration and rolling back to specific versions of the code. Seems like it makes operational tasks, and really anything that involves distributing the code to anyone who is not the developer, is more difficult than with non-image based languages.

scroot 5y ago
There have been several different version control systems available for most Smalltalks for a while now. In the big open source Smalltalks (Squeak, Pharo, etc) there is even Git integration.
xkriva11 5y ago
Pharo has all this solved quite well.
- jimbokun 5y ago
  Can you elaborate?
  - xkriva11 5y ago
    Pharo uses libgit2 binding and adds nice tools on top of it. The development of Pharo itself is based on Git/Github. So it uses standard Git workflow with branches, pull-requests, CI building and testing etc., but because it has methods based granularity, it is even better than plain Git for operations like merging and cherry-picking (it can, for example, easily resolve conflicts that plaintext based Git cannot). Moreover, it allows things like listing the history of a particular method. Even CI building can benefit from still-present image capabilities because you can have a basic prebuild image with project dependencies and then just load what you are really interested in in a few seconds (while still having an option to bootstrap it completely).
    - jimbokun 5y ago
      That sounds pretty cool.
emschlr 5y ago
Can't we just deploy the Smalltalk or Common Lisp code and not make changes to the live image? Then we can deploy Smalltalk/Common Lisp projects just like we deploy Python/Ruby prjoects. Can't we?
- vindarel 5y ago
  For Common Lisp: sure we can. We can run a program from the sources, as a script, just like Python, and we can build a binary, with all dependencies baked in. CL has the feature to save the current image: it's excellent for development (see how Ravenpack ships images with several GBs of data baked in: the image will start instantly, you won't have to wait for your development data to be initialized again). And we can run the Lisp program and not touch it. But… if we want, we can easily connect to the running Lisp image, introspect it, change a couple parameters… or do a software upgrade, which can involve installing Lisp libraries… and we could connect to the image on the remote server from our editor and develop the app (while still saving the changes in source control locally), but that would be silly and it isn't a standard way.
- scroot 5y ago
  Yeah, just don't save the image. Whenever you restart the program use a fresh image. This is pretty much indistinguishable from a "normal" program's state when it is running.
- igouy 5y ago
  Here are some libraries and a program in Smalltalk Interchange Format being loaded into a Smalltalk image, the image being saved, and the saved image being used to run the program on the command line — https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-vw-1.html#log https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ./bin/visual nbody.vw_run.im -nogui -pcl MatriX -filein nbody.vw -doit 'ObjectMemory snapshotThenQuit' ... ... ./bin/visual nbody.vw_run.im -nogui -evaluate "BenchmarksGame do: 50000000" ... ... -0.169075164 -0.169059907
vindarel 5y ago
What CL versions could they be? Even in versions with their own, very interactive IDE (LispWorks), we work with source files, with git and all, and we can run a program either from the sources as a script or from a pre-built binary (which is built from clean sources, not from our development image).
rbanffy 5y ago
I once interviewed James Gosling and one of the questions was precisely that - what did Smalltalk do wrong and what did Java do right for one to fail and the other to dominate the market? The “doesn’t play well with others” problem of Smalltalk was kind of a killer.
- igouy 5y ago
  Might he possibly have had an agenda to promote? :-)
  - rbanffy 5y ago
    At that point I doubt it. I was expecting that answer in fact. Smalltalk had a couple problems Java didn’t. Its syntax scared people used to C while Java made them feel comfortable. The tooling was also free, which was not the case for Smalltalk at the time. Finally, the idea of storing source code inside a memory image didn’t help with interoperability (something I also observed while working with Zope).
    - igouy 5y ago
      "The Rise and Fall of Commercial Smalltalk" discussions provide a fuller picture: https://news.ycombinator.com/item?id=29223880 https://news.ycombinator.com/item?id=29223880 > … storing source code inside a memory image didn’t help with interoperability… "Interoperability" covers a lot of things, was there something particular you had in mind?
      - rbanffy 5y ago
        In this case it was about being adaptable to the tools programmers already used. Smalltalk required one to buy into the whole thing - it’s an IDE with its own OS and GUI.
        igouy 5y ago
        What if those already-used tools weren't as-good for writing Smalltalk programs? ---- > … its own OS and GUI. Well there are examples of bare metal Smalltalk (I'm guessing we could say the same of Java?) https://github.com/michaelengel/crosstalk but that was kind-of unusual and afaik commercial Smalltalk implementations targeted specific host OSes. ---- Similarly back in the '80s commercial Smalltalk implementations provided their own GUI L&F (and in the '90s Java provided their CrossPlatformLookAndFeel aka Metal). When OS GUIs became available in the '80s, Smalltalk implementations either targeted specific host OS GUIs (so on MS Win use MS Win controls) or provided portable GUIs based on emulated L&Fs (OS/2, Motif, MacOS, MSWin) (and in the '90s Java provided AWT/Swing…). IBM Smalltalk (Visual Age) GUIs were based on what would become in the '90s Java SWT. ---- So no, not really "its own OS and GUI" — when GUIs became provided by the host OS, Smalltalk implementations provided ways to use the platform L&F.
igouy 5y ago
> … common complaint… For sure! Is it a well-founded complaint or just an obvious difference? What if the Smalltalk image is a cache not an archive? What if source code is exported from the image as text files and archived, and each week the source code is loaded into a base image for test? https://news.ycombinator.com/item?id=29911384 https://news.ycombinator.com/item?id=29911384

scroot 5y ago

There have been several different version control systems available for most Smalltalks for a while now. In the big open source Smalltalks (Squeak, Pharo, etc) there is even Git integration.

xkriva11 5y ago

Pharo has all this solved quite well.

jimbokun 5y ago
Can you elaborate?
- xkriva11 5y ago
  Pharo uses libgit2 binding and adds nice tools on top of it. The development of Pharo itself is based on Git/Github. So it uses standard Git workflow with branches, pull-requests, CI building and testing etc., but because it has methods based granularity, it is even better than plain Git for operations like merging and cherry-picking (it can, for example, easily resolve conflicts that plaintext based Git cannot). Moreover, it allows things like listing the history of a particular method. Even CI building can benefit from still-present image capabilities because you can have a basic prebuild image with project dependencies and then just load what you are really interested in in a few seconds (while still having an option to bootstrap it completely).
  - jimbokun 5y ago
    That sounds pretty cool.

emschlr 5y ago

Can't we just deploy the Smalltalk or Common Lisp code and not make changes to the live image? Then we can deploy Smalltalk/Common Lisp projects just like we deploy Python/Ruby prjoects. Can't we?

vindarel 5y ago
For Common Lisp: sure we can. We can run a program from the sources, as a script, just like Python, and we can build a binary, with all dependencies baked in. CL has the feature to save the current image: it's excellent for development (see how Ravenpack ships images with several GBs of data baked in: the image will start instantly, you won't have to wait for your development data to be initialized again). And we can run the Lisp program and not touch it. But… if we want, we can easily connect to the running Lisp image, introspect it, change a couple parameters… or do a software upgrade, which can involve installing Lisp libraries… and we could connect to the image on the remote server from our editor and develop the app (while still saving the changes in source control locally), but that would be silly and it isn't a standard way.
scroot 5y ago
Yeah, just don't save the image. Whenever you restart the program use a fresh image. This is pretty much indistinguishable from a "normal" program's state when it is running.
igouy 5y ago
Here are some libraries and a program in Smalltalk Interchange Format being loaded into a Smalltalk image, the image being saved, and the saved image being used to run the program on the command line — https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-vw-1.html#log https://benchmarksgame-team.pages.debian.net/benchmarksgame/... ./bin/visual nbody.vw_run.im -nogui -pcl MatriX -filein nbody.vw -doit 'ObjectMemory snapshotThenQuit' ... ... ./bin/visual nbody.vw_run.im -nogui -evaluate "BenchmarksGame do: 50000000" ... ... -0.169075164 -0.169059907

vindarel 5y ago

What CL versions could they be? Even in versions with their own, very interactive IDE (LispWorks), we work with source files, with git and all, and we can run a program either from the sources as a script or from a pre-built binary (which is built from clean sources, not from our development image).

rbanffy 5y ago

I once interviewed James Gosling and one of the questions was precisely that - what did Smalltalk do wrong and what did Java do right for one to fail and the other to dominate the market? The “doesn’t play well with others” problem of Smalltalk was kind of a killer.

igouy 5y ago
Might he possibly have had an agenda to promote? :-)
- rbanffy 5y ago
  At that point I doubt it. I was expecting that answer in fact. Smalltalk had a couple problems Java didn’t. Its syntax scared people used to C while Java made them feel comfortable. The tooling was also free, which was not the case for Smalltalk at the time. Finally, the idea of storing source code inside a memory image didn’t help with interoperability (something I also observed while working with Zope).
  - igouy 5y ago
    "The Rise and Fall of Commercial Smalltalk" discussions provide a fuller picture: https://news.ycombinator.com/item?id=29223880 https://news.ycombinator.com/item?id=29223880 > … storing source code inside a memory image didn’t help with interoperability… "Interoperability" covers a lot of things, was there something particular you had in mind?
    - rbanffy 5y ago
      In this case it was about being adaptable to the tools programmers already used. Smalltalk required one to buy into the whole thing - it’s an IDE with its own OS and GUI.
      - igouy 5y ago
        What if those already-used tools weren't as-good for writing Smalltalk programs? ---- > … its own OS and GUI. Well there are examples of bare metal Smalltalk (I'm guessing we could say the same of Java?) https://github.com/michaelengel/crosstalk but that was kind-of unusual and afaik commercial Smalltalk implementations targeted specific host OSes. ---- Similarly back in the '80s commercial Smalltalk implementations provided their own GUI L&F (and in the '90s Java provided their CrossPlatformLookAndFeel aka Metal). When OS GUIs became available in the '80s, Smalltalk implementations either targeted specific host OS GUIs (so on MS Win use MS Win controls) or provided portable GUIs based on emulated L&Fs (OS/2, Motif, MacOS, MSWin) (and in the '90s Java provided AWT/Swing…). IBM Smalltalk (Visual Age) GUIs were based on what would become in the '90s Java SWT. ---- So no, not really "its own OS and GUI" — when GUIs became provided by the host OS, Smalltalk implementations provided ways to use the platform L&F.

igouy 5y ago

> … common complaint… For sure! Is it a well-founded complaint or just an obvious difference? What if the Smalltalk image is a cache not an archive? What if source code is exported from the image as text files and archived, and each week the source code is loaded into a base image for test? https://news.ycombinator.com/item?id=29911384 https://news.ycombinator.com/item?id=29911384