Smalltalk traditionally breaks this source vs. executable state dichotomy by using a single memory image where everything is an editable object, including the classes that contain the code. For persistence, the image is simply stored and reloaded in its entirety.
Would this be a good fit for Smalltalk, as it is image based? It seems it can remove a level of complexity, if you can treat your image, and so all your objects, as constantly persisted?
It covers some of the minimal syntax of Smalltalk but didn't touch on Smalltalk images, which is a major signature of Smalltalk.
A Smalltalk image contains every Smalltalk object. This includes classes (which are Smalltalk objects), instances of the classes, source code, the current running state, everything. You work within the image and interact with it.
Think of the image as a copy of your IDE, along with the compiler, your current project's source code, the compiled classes, methods, everything. You can save your image (state) at any time, not unlike the sleep feature of Windows and Mac. It's a live environment. During a programming session, you edit and save the code of class (it's automatically compiled) and every instance of that class is updated. This sounds like what you commonly have in many dynamic languages, but Smalltalk takes it to an extreme. You can re-configure your "IDE" as you go along since they are running in the same image, all the classes and objects are accessible. Or you can set breakpoints and step through code, changing code on the fly and resuming, all without stopping the "program" and starting again. Not unlike a graphical REPL.
Does anyone know if there's a similar tool utilizing the same concept other than Self?
AFAIK both Lisp and Smalltalk environments are image based. That is, all source code and all objects are stored in memory. You need to save that image in order to continue from where you left off. Snapshots are also used to allow rollback to previous "good" states.
Smalltalk tries to solve the problem of mutable state in a unique way. Where some languages say "mutable state is bad, minimize or isolate state changes," Smalltalk gives you amazing tools for monitoring the state of objects in the system. The level of control at every level of execution is unlike any other language. You can open up live inspectors on any object, edit a method in the debugger and restart the stack frame you are looking at, and persist all of it across programming sessions in the image.
I had a similar realisation recently. I had to learn Smalltalk recently (for my new job, believe it or not!), and Smalltalk really does strike me as image-based programming find right. My previous exposure was Common Lisp, but the image and the source code getting desynchronized was a recurring pain. After deleting a function, but missing some uses for example, the code might work fine until you reloaded the source into a clean image. In Smalltalk, that doesn't happen, because the image is the code.
When they say that in Smalltalk, everything's an object, they're seriously not kidding. Everything is an object, including compiled code, stack frames, execution contexts, threads, etc. A traditional Smalltalk system uses an object table, where all object pointers are really references to a slot in the table; this allows the garbage collector to move objects around in memory easily.
This means that it becomes trivial to dump everything out to disk, reload it later, update the object table, and suddenly the entire state of your system is restored (ignoring host OS resources, of course, but traditionally Smalltalk didn't use an operating system).
I did have a handy sample for GNU Smalltalk that would snapshot an image containing a running thread which, when the thread was reloaded, would seamlessly resume but, er, I seem to have lost it.
Even then, I heard Smalltalk development was like Lisp, with the ability to do incremental compilation / image based development where you initiate an image that represents a process with built-in, generic saving functionality and the ability to edit the code while it runs. You could start an image, run it, build the program as it runs, save it, restart the computer, and continue the image so it runs from the point it was saved. Here's some online documentation that describes that[1].
There's also REPLs for Smalltalk, but none for Java due to it's syntactic structure that prevents top-level statements.
That sounds like Smalltalk leads to far different development experiences compared to Java.
In other words, I can't think of how anything between Smalltalk and Java could be similar (at least more so than comparing it to any other programming language). Could you expand on that?
Smalltalk - the granddaddy of all object oriented languages, and still the 'most' object oriented IMHO. And the only language that I know of that is typically implemented in a system that offers image based persistence, which is very cool (again IMHO).
Janet's object system seems to be modeled after ideas first popularized in the Self language -- a Smalltalk derivative -- so there could be some direct inspiration there.
> I sometimes say that the image-based part of Smalltalk is like Lisp, but done right, because the state of the code in your image and the state of the code in your source files can't ever get out of sync; the IDE is the image.
That's what Interlisp did too. Particular Interlisp-D and its later version Medley.
In Smalltalk, you can manipulate objects directly rather than just indirectly via code that operates on them. The state of your manipulation is made persistent in smalltalk's image facility. Also, the whole object graph is supposedly better exposed accordingly then what you could get sigh just a plain old debugger.
At least I think that is what the author is trying to convey.
Smalltalk is designed around this functionality. In fact the whole Smalltalk system is a live instance that has been modified like that since development started.
With respect to the semantics of the system, a Smalltalk object is supposed to be a full Turing machine (sometimes universal, but often times special-purpose), which is the same thing as a process.
I mentioned Docker because of the similarity to the Smalltalk image.
Do you know how "image based" environments work? In short you live in the same space as your code, so when you write some new method you have access to all the "dynamically and non deterministically" code artifacts. With Smalltalk the code is always being run and you get many useful tools for querying the state of a running system. I know it's hard to believe, but you can get much better completion (not to mention refactoring support) with this approach than you get from static analysis.
Sometimes, when battling these issues, I wish the Smalltalk-style approach[1][2] was more popular/feasible. Basically, saving the entire state of the VM is a fundamental operation supported by the language. Only truly transient things like network connections require special effort.
There are some echoes of this with things like Lua's Pluto/Eris, or serializable continuations in other languages (eg: Perl's Continuity).
It's just such a pain to thoroughly handle that sort of stuff without language-level support. And doing a "good enough" approach with some rough edges is usually shippable, so it's hard to build a critical mass of demand for such support. And even if there was, it's very hard to add it to a language/framework/etc that wasn't designed for it to begin with.
I've had a decent experience with 'struct string' style approaches, like Lua's string.pack() or Perl's pack()[3]. It's a little brittle, but extremely straightforward and "not framework-y," which suits me. But it leaves out things like program execution state; it's just for plain data.
reply