Hacker News Reader

Comment by otakucode | Hacker News Reader

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.

View on HN

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?

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

That's what I loved best about Smalltalk. You could just hard quit out of the image, then go back to the Change Log and replay all but the last few changes. If you save off an image every day or so, you're always back in minutes, no matter how dangerously you've been coding.

There are a variety of utilities which let you load code quickly. Most often, deployment was done using one of these loading onto a clean or a stripped image. You can certainly control changes to your environment. In fact, I'd say you can often control them more easily than in other environments.

you have no idea why -- is it a genuine bug or did it happen few minutes ago, when the function was still incomplete?

The Change Log makes it very easy to figure that out. All of your ad-hoc "command-line" (do-it) state changes to the image are recorded there as well.

This is a great insight but when I read things like this it reminds me the Smalltalk advocates need to do a better job adressing the concerns of the broader development community. It seems like they spend too much time addressing things that aren't concerns and not enough time on things that are.

That can happen, but typically you're not keeping state around for huge periods of time (though you can if you want), it's just a convenience while you rapidly iterate on the design of the code. Once you've got code that seems to hang together well, it's time to start thinking about what the right way to instantiate the objects, to consistently bring them to a correct state. Unit tests are useful for this, and with a brief (ab)use of a global variable, you can often make the tests run against your hand-made object, and verify that the test results are the same as when testing a properly instantiated object. After that you can dispense with your hand-made instance.

Somewhat related, you can use unit tests of as-yet unimplemented functionality as a jumping-off point for live-coding your way towards the right implementation, with the debugger acting as a combined code editor and REPL (since the formal parameter names in the code will have real, evaluatable values behind them - as supplied by the test case).

Were I a major Test Driven Development adherent, I might claim that this is the non-cargo-cult way of doing TDD.

All this works perfectly well in Common Lisp too.

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

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

No you don't manage and back up using images (you can of course). Instead you manage and back up diffs just like you would in any other language. You can do that from inside or outside the VM. From the outside, the VM writes it's changes to a change (diff or journal) file and you get to choose when and if you're going to commit those changes. You can use that file to make commits to your SCM.

> So we're back to…

No, that's a bizarre suggestion you just invented, it has nothing to do with what I wrote.

The development workflow for Pharo is that every code change has a CI performs a bootstrap build of the whole system pulled from a git repository. Then your CI adds your production code on top of that.

So it doesn't get lost in the mass of other comments, here again is some info on Pharo's bootstrap process... http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...

You may be interested in the bootstrap work Pharo has been doing...

http://www.esug.org/data/ESUG2016/04-Thursday/1000-1030%20Mi...

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.

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.

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.

Thanks for clarifying my comment with actual experience. Much appreciated!

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

Also self

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

Because you have had experience with them, or because you haven't had experience with them?

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

Reply on news.ycombinator.com