[db48x]

Most of those "advances" have nothing to do with files or images at all.

For testing it doesn't matter where the tests come from. Certainly some test environments look for tests in files with predetermined names, or in particular directories, but that's an implementation detail. Look at Rust for a modern compiled file-based language that completely avoids that; instead you tag individual functions with metadata to indicate that they are tests. At build time you can create both a normal binary and a test binary; the first is the program you wrote, the second runs the tests that you wrote.

REPLs and a mixed compiler/interpreter were both invented by Lisp, which is largely image-based. They go hand-in-hand; code you enter at the REPL might start out interpreted, but you can always call the compiler (at run time) to speed up functions you care about (or let the system do it automatically).

The static vs dynamic language divide has nothing to do with how the code is stored, but historically languages with REPLs have indeed been dynamic languages.

I don't know about Smalltalk specifically, but Common Lisp has a great package system, and with Quicklisp it's a fully modern one with automatic package installation, dependency management, version pinning, and everything. Of course, Common Lisp these days is a hybrid system. Your code is stored in files, and when you load them into memory to create an image. If you care about startup time you can dump that image out so that it loads all at once. Quicklisp just has to download a tarball of files and stick them in your load path for you; I don't know precisely this is done in Smalltalk.

Both Lisp and Smalltalk have a facility for writing code out to a file to be printed, sent across the network, etc. This is how collaboration is done. You write the code in your environment, test it, etc. Then you write it out to a file and send it to whoever. (Or your version control system puts it in a file for you when you commit, etc.)

[theamk]

Well, I was responding to specific parent's statement: "Being shackled to existing file-based tools holds you back from improving the software development process." This seems to imply to me that non-file-based tools have some other improvements to software development process.

I think both you and I agree that software development process improves mostly independently from file-based/image distinction. There are no visible ways when files are "holding back" the software development.

[bencoman71]

Everyone sees the world through their own eyes, filtered by what their past and what know.

A peculiar perspective of Smalltalk programmers is to consider that "code in files is dead code". External tools are needed to query it, modify it, compile it.

In Pharo you can evaluate... Integer methods first inspect

and in different tabs you can see this method's source code, the AST, the compiled bytecode.

Or in a similar way we can look at how PLUS is implemented by evaluating (Integer>>#+) inspect

Or look at all the methods that use PLUS

    #+ senders inspect

Within Smalltalk, classes and methods are themselves objects. You can operate on them like any other object. They are ALIVE!!! AHAhahaHaaaaa :)