That said, I too find it a bit disturbing not to be able to import/export changes to the base image as text-files and being unable to build a clean image from source-code only.
That said, I too find it a bit disturbing not to be able to import/export changes to the base image as text-files and being unable to build a clean image from source-code only.
I also find that disturbing. Another vthing i find disturbing, which may be a related problem is that although Smalltak lets you do all sorts of cool things like rotate its menus 30 degrees while the application is still running, often it just doesn't do what I expect for no apparent reason (other Smalltalk programmers seem to have the same experience). I suspect this progem is related to the fact that you can't simply get the state of the system as a set of text files. For me, at least, developing in Smalltalk feels a bit like walking around wonderingg whether I'll fall in the quicksand.
But can you do this in Smalltalk? OK, you have inspectors that show you a representation of your data, but the representation is incomplete. I haven't used Smalltalk in years, so I'll gave an example in Python to show what I mean:
>>> a = [1,2]
>>> b=[a,a]
>>> c=[[1,2],[1,2]]
>>> b
[[1, 2], [1, 2]]
>>> c
[[1, 2], [1, 2]]
>>> b[0][0]='x'
>>> b
[['x', 2], ['x', 2]]
>>> c[0][0]='x'
>>> c
[['x', 2], [1, 2]]
(b) and (c) initiallly have the same representation, but they behave differently. I don't like this, so I'm creating a language where the text representation of an object defines how it behaves: if two objects have the sdame representation, their internal structure is the same, and their behaviour will (with one exception) be the same. This representation format is used as a serialisation format, and is also used to write literals in the language. This means that it's possible to display precisely the value of any object, including all the sub-objects it contains.It's a different language, but I found this paper on making SBCL (a lisp compiler) build from source interesting: http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf
The previous situation was that the CMUCL compiler, which SBCL forked from, was essentially defined by the image, which was incrementally changed into new versions--- and over decades this process had made the source code that was nominally "the CMUCL source" increasingly different from the in-memory image that was actually CMUCL.
I still find the image-based model vaguely fascinating in its blurring of the compile-time/runtime distinction, something that occasionally gets resurrected under various guises: http://en.wikipedia.org/wiki/Interactive_programming