> I'm primarily a Schemer, so correct me if I'm wrong, but lisp, at least since the death of the lisp machine, doesn't have an image: it has a live environment in RAM, and there's no easy way to dump that to disk. It's just a REPL.
This is true of many Scheme environments. Some Scheme environments do support the image-based development model, and at least Scheme48 uses it exclusively for compiled code.
However, it's more common to find image-based development in other Lisp dialects. In the case of Common Lisp, for example, have a look at this[0] paper on the SBCL bootstrap process.
> And this is where the misunderstanding stems from: The image is a live environment, yes, but it is also your entire application, and your source code: When you hit 'save' in a smalltalk image, all of your code, as well as a snapshot of the state of every single object in the system, is saved to disk. There is no file to forget to add things to. If you added it live, it's in your system, same as if you'd typed it into a text file in lisp.
Right. Perhaps an example would help clear up what I mean: Say you have an application in some Smalltalk environment, but you want to bring that application up in some other Smalltalk environment (on another platform, for example). All of your code is stored within image A for the original environment, and you have a fresh image B for the other environment. How do you reproduce image A for the new environment starting with image B? If your source code is stored in files, you can easily enough just load those files into the new environment.
On the other hand, I really don't understand what kind of benefits you gain by doing all of your programming in a live environment. I always felt the same way about Lisp's REPL: the interactive interpreter is handy for quickly testing out some code for sure, but I wouldn't want to write my entire application in an interactive interpreter. Why? Because if my sources are represented in plain text files, I can use any number of specialized tools to query and process them. This is the kind of thing people mean when they say things like "Unix is my IDE", and why I am the most productive with Vim open next to a shell prompt and a REPL.
> It's not. Which is why Smalltalk has its own version control system, and (I believe), a git bridge, allowing you to save only your classes, your projects, and what you've changed to a repo, and download them to other images.
It seems that this would solve some of the issues I raised, especially the ability to download into other images. The last time I played with Squeak, there wasn't any git bridge (in fact, there may not have been any git whatsoever... it was quite some time ago), and any builtin version control was pretty awkward and limited.
> You're still thinking in terms of files: In a smalltalk vm, the browser isn't organizing files: it's organizing classes. And you can sort those classes into packages, and the methods into protocols. Not perfect, but pretty good.
Yes, I am thinking in terms of files. I was trying to make the point that using files gives the programmer far more flexibility in organization, which I see as an advantage compared to using an image. Furthermore, most of the IDEs I've used offer package/class/method browsers on top of files, giving the best of both worlds. Take Eclipse for example: its navigation pane displays a hierarchy of packages, classes, and methods -- it's effectively the same as using the Smalltalk class browser, but the underlying storage is based on a file hierarchy which has been processed by the IDE.
> An ST environment can query, navigate, and explore the objects that text represents, and tell you far more about what your code is doing that any text editor.
I don't believe that one bit, especially considering that there is a variety of tools available for processing text files beyond just a text editor (and, of course, any text editor worth its weight in bits can interface with external programs).
One thing to understand regarding Smalltalk, it is the paradigm shift compared to file based environment:
- with the later, you deal with characters (ascii, utf8)
- with the former, you deal with object (an internal object representation).
So indeed the tooling is different. One deal with text processing, the other with object processing. The benefits you get are different. The browsers in Eclipse and Smalltalk are not processing the same thing, an Object is a far more abstracted representation of your source code, for example the browser can ask to an Object can you do 'that' kind of processing, or do you accept I send this message (method call in other language), etc.
When developing, the image is your sandbox environment with object representation of your code, but of course Smalltalk developers also save their code in text file representation, but it is only mean as a backup and transportation scheme from an image to another image. AFAIK, it is never uses for anything else than transporting or comparing source code version; not because we can't do it, but because we don't need to it.
The question regarding the source code file arises very often on Smalltalk. Not because Smalltalk is doing wrong there, but because it is a paradigm shift, and as you know we are all more or less conservative regarding changes or different point of view; some fellow free software activists disregard me to use such an awkward environment, but at least RMS did not get problem GNU DrGeo moved to the Pharo platform once I explain the underneath system, and that the access to the source code from the VM up to the Pharo environment was plain free software licensed as MIT licence.
To sum up:
- the image is the sandbox where you deal with object
- we save code in file (one monolithic file, or small granulated one file per method) for back up, versioning, transportation
- the developer may from time to time, decide to take a fresh image and reload his source code
- delivered Smalltalk application are built from a fresh image and source code installation from the source file of the code. For http://drgeo.eu I use a combination of Smalltalk script and Bash script to build the delivered application for GNU-Linux/MacOSX/Windows.
-
This is true of many Scheme environments. Some Scheme environments do support the image-based development model, and at least Scheme48 uses it exclusively for compiled code.
However, it's more common to find image-based development in other Lisp dialects. In the case of Common Lisp, for example, have a look at this[0] paper on the SBCL bootstrap process.
> And this is where the misunderstanding stems from: The image is a live environment, yes, but it is also your entire application, and your source code: When you hit 'save' in a smalltalk image, all of your code, as well as a snapshot of the state of every single object in the system, is saved to disk. There is no file to forget to add things to. If you added it live, it's in your system, same as if you'd typed it into a text file in lisp.
Right. Perhaps an example would help clear up what I mean: Say you have an application in some Smalltalk environment, but you want to bring that application up in some other Smalltalk environment (on another platform, for example). All of your code is stored within image A for the original environment, and you have a fresh image B for the other environment. How do you reproduce image A for the new environment starting with image B? If your source code is stored in files, you can easily enough just load those files into the new environment.
On the other hand, I really don't understand what kind of benefits you gain by doing all of your programming in a live environment. I always felt the same way about Lisp's REPL: the interactive interpreter is handy for quickly testing out some code for sure, but I wouldn't want to write my entire application in an interactive interpreter. Why? Because if my sources are represented in plain text files, I can use any number of specialized tools to query and process them. This is the kind of thing people mean when they say things like "Unix is my IDE", and why I am the most productive with Vim open next to a shell prompt and a REPL.
> It's not. Which is why Smalltalk has its own version control system, and (I believe), a git bridge, allowing you to save only your classes, your projects, and what you've changed to a repo, and download them to other images.
It seems that this would solve some of the issues I raised, especially the ability to download into other images. The last time I played with Squeak, there wasn't any git bridge (in fact, there may not have been any git whatsoever... it was quite some time ago), and any builtin version control was pretty awkward and limited.
> You're still thinking in terms of files: In a smalltalk vm, the browser isn't organizing files: it's organizing classes. And you can sort those classes into packages, and the methods into protocols. Not perfect, but pretty good.
Yes, I am thinking in terms of files. I was trying to make the point that using files gives the programmer far more flexibility in organization, which I see as an advantage compared to using an image. Furthermore, most of the IDEs I've used offer package/class/method browsers on top of files, giving the best of both worlds. Take Eclipse for example: its navigation pane displays a hierarchy of packages, classes, and methods -- it's effectively the same as using the Smalltalk class browser, but the underlying storage is based on a file hierarchy which has been processed by the IDE.
> An ST environment can query, navigate, and explore the objects that text represents, and tell you far more about what your code is doing that any text editor.
I don't believe that one bit, especially considering that there is a variety of tools available for processing text files beyond just a text editor (and, of course, any text editor worth its weight in bits can interface with external programs).
[0]: http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf