Hacker News Reader

Comment by jimbokun | Hacker News Reader

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.

View on HN

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.

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?

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.

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.

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/...

    ./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

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).

> … 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

Pharo has all this solved quite well.

Can you elaborate?

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).

That sounds pretty cool.

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.

Might he possibly have had an agenda to promote? :-)

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).

"The Rise and Fall of Commercial Smalltalk" discussions provide a fuller picture:

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?

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.

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.

> … storing source code inside a memory image didn’t help with interoperability…

Here's some "play well with others” "interoperability" —

Sept 21, 1987 — "A version of the Smalltalk-80 object-oriented development environment … has been announced by Parcplace Systems.

Smalltalk-80 DE version 2.2 is said to provide Unix environments with interprocess communication via sockets and access to Unix C shells. On the Apple Macintosh, it provides access to Desk Accessories and provides the ability to cut and paste between the Smalltalk-80 system and the clipboard."

https://books.google.com/books?id=ldk7z4Q-WWYC&pg=RA4-PA4&lp...

Reply on news.ycombinator.com