5 ms·

I'm familiar and reasonably comfortable with the "image" concept from Lisp, but frankly I think outside of prototyping it's an inferior way to program. When yo

I'm familiar and reasonably comfortable with the "image" concept from Lisp, but frankly I think outside of prototyping it's an inferior way to program. 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.

qwertyuiop924 10y ago
>I'm familiar and reasonably comfortable with the "image" concept from Lisp, 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.

qwertyuiop924 10y ago

>I'm familiar and reasonably comfortable with the "image" concept from Lisp, 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.