When you're doing some sort of exploratory/experimental programming or trying to incrementally prototype some program, the ability to modify a live environment is fine, but it's only just barely better than coding in a file, and only because it saves you a small amount of time.
But once you're ready for distribution, images have a ton of drawbacks. For example:
* The running image is either particular to some physical machine, or it's constrained to a virtual machine, leaving you to pick one of portability or efficiency.
* I have to believe that there's some way to remove the development environment from the final image, but I didn't find a way to do that with Squeak when I tried it -- if there's really no way to do that, then suddenly your production image includes a full development environment in addition to your application, costing you and your customers unnecessary storage space, memory, and bandwidth.
* There's also a question of how well the environment within the image can communicate and interact with the host environment -- from the end user's point of view, it looks and behaves differently from everything else they use; how is it for the programmer?
The biggest problem with the image-based development style is reproducible builds. If your application has been created by incrementally tweaking a live environment here and there, how do you make that reproducible? How can you then save all the necessary code and data to recreate that state from a fresh image? Lisp solves the issue by supporting the file-based paradigm in addition to the image one, with constructs like LOAD, COMPILE, and COMPILE-FILE. At a higher level, Lisp also has a notion of "systems", which can be defined in a file and describe how to map a set of files to a final product (c.f. ASDF). Even in Lisp, however, you run the danger of forgetting about some change you made to the image and forgetting to include it in your source files. How would you do any of this in Squeak?
Along the same lines, how would you work with source control? Checking an image into git doesn't seem like an ideal solution.
In regard to code organization: files let developers organize the code however they feel is best, not the way some browser author decided is best. The idea of cohesion isn't just a sound engineering principle -- it's also a sound stylistic principle that can aid understanding of a system. Furthermore, a good text editor can help with navigating, exploring, querying, and processing text as well. Text editors aren't somehow limited to only enabling writing -- they have features to assist in reading and comprehending text, too.
I, for one, never felt more productive in any Smalltalk-type environment I've ever used, and such a development model seems to have quite a few drawbacks in exchange for only very few, very minor advantages.
With experience programming complex applications both on C++ and Smalltalk, I have experienced coding in a live environment is all but a tiny advantage, it is a real productivity booster. The more complex your application the more productivity gain you have. In an interactive geometry application as Dr. Geo (http://drgeo.eu) , the combined use of in-situation inspector, debugger and live code editing on graphic geometry items, ease issues finding and fixing. Fixing issues is much more easier and pleasant thanks to the developer tooling. This is not without mentioning other advantages as a better source code access and understanding thanks to the class browser. In C++ I was using Emacs.
> I have to believe that there's some way to remove the development environment from the final image, It really depends on the Smalltalk implementation. I heard Dolphin Smalltalk (http://www.object-arts.com/) or Smalltalk X (https://www.exept.de/en/smalltalk-x.html) are really good at that. Pharo itself is doing progress in that specific direction.
The way you explain the advantages, it seems like the live environment is much more beneficial when developing highly interactive applications, perhaps GUI applications especially, but the advantages of the live environment wouldn't come into play so much when developing non-interactive, "batch mode" applications. Do you think that's a fair assessment?
If so, then perhaps one reason I didn't find much value in the Smalltalk environment is that I wasn't developing interactive applications. With batch applications, I've come to find that even classical debuggers aren't quite as helpful as they are with interactive applications, because depending on how long it takes your program to run, it can often be faster to run a test case and inspect the log than to set a few breakpoints and step until you find your problem.
In my experience live environment brings added values when you need to fix issues arising in the middle of a complex process of data and state computation or manipulation. In such situation, logging errors, fixing, rebuild, rerun, positioning the program states where the errors raised is very time consuming (and frustrating) than fixing in the live environment where you just need to recompile the faulty code (method granularity), adjust the data and resume the execution of the program from there.
In my experience it is true for GUI interactive application, fixing non interactive algorithm, processing data, web application.
By batch mode, I guess you mean processing data. If the process is complex, the live environment will help to get more quickly a proper and safer code. But may be in that case, you want a small script or executable you can move along easier than the Smalltalk environment. That's an area of use I don't know with Smalltalk and Smaltalk was not designed for that use case, although it seems people are using it too as a script tool. I will interested to read about that use cases too.
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.
>I have to believe that there's some way to remove the development environment from the final image, but I didn't find a way to do that with Squeak when I tried it
You certainly can, presumably just by stripping them out, but I'm not 100% sure, as I've never tried. MIT did it though, back in the days of squeak 2.X, leading to MIT Squeak, which is Squeak stripped down to just the bare necessities to develop Scratch. They didn't remove the class browser, workspace, transcript, or debugger, but I imagine it wouldn't be too hard, and besides, if there was a problem with your code in production, you'd want them there.
>There's also a question of how well the environment within the image can communicate and interact with the host environment -- from the end user's point of view, it looks and behaves differently from everything else they use; how is it for the programmer?
Squeak's got an FFI, and has binding for network access, etc., but one of smalltalk's greatest failings is its inability to play well with others. Scratch 1.X is probably the best example of a Smalltalk UI in action that you'll see, and you can see how foreign that looks.
>The biggest problem with the image-based development style is reproducible builds. If your application has been created by incrementally tweaking a live environment here and there, how do you make that reproducible? How can you then save all the necessary code and data to recreate that state from a fresh image?
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.
>Along the same lines, how would you work with source control? Checking an image into git doesn't seem like an ideal solution.
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.
>In regard to code organization: files let developers organize the code however they feel is best, not the way some browser author decided is best.
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.
>Furthermore, a good text editor can help with navigating, exploring, querying, and processing text as well. Text editors aren't somehow limited to only enabling writing -- they have features to assist in reading and comprehending text, too.
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.
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
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. -
Smalltalk'ers believe that code should be optimized for reading, not writing, which is why Smalltalk code browsers focus far more on organization than any other languages IDE's do and the power of this cannot be emphasized enough.
Simply put, once you let go of your text editor addiction, and embrace the image, it's the most productive programming environment there is as far as Smalltalk'ers are concerned.