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?
Interesting, how image-based development can make a big difference in comprehensibility at the expense of more complicated sharing.
One thing I like about Smalltalk is I don't have to wonder what the process is to get to a certain place in the code very often. There's a lot less scaffolding and construction code than with a typical start-from-main program. Little pieces can be tested directly to see how they work.
Run-time program modification is possible, to a certain extent, when debugging or using libraries like JRebel, which I mentioned.
Again I am not saying you can do everything that Smalltalk allows for, after all it enjoys the flexibility of a dynamic language, just that those environments (.NET and Java) are the closest to the overall experience, from the point of view of someone that used Smalltalk/V back in its golden days.
The dynamism of those IDEs can be traced back to what Xerox PARC was doing on their Mesa/Cedar developer's environment.
Smalltalk has live update of the running program, arguably in a much better way than (modern) Lisps. In Smalltalk you edit code directly in the running image, there's no possibility of defining a function in the REPL and having a different definition in a source file somewhere: the source is the image, and any change to code is reflected in the image. The old Lisp machine Lisps (like Interlisp) used to do this too, I think, but no CL implementation I know of does this anymore.
The Smalltalk debugger is famously also implemented in the development image (and implementing a simple debugger is a common project in Smalltalk textbooks). Traversing the stack, accessing locals, stepping, etc. are of course all possible.
No CLOS in Smalltalk admittedly, but lots of shenanigans are possible by fiddling with the object model.
Likewise no macros, but Smalltalk syntax is so minimalistic that creating control structures that look like the built-ins is trivial. In fact, conditionals, loops and the like are entirely unmagical in Smalltalk (modulo performance optimizations to make things go fast); reimplementing conditionals (that look and work exactly like the standard set) for example is trivial.
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.
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.
Smalltalk has a concept of changesets. They can approximate diffs/patches.
And while the code is exposed in code browsers (some kind of IDE/text editor window) in the image, and not exposed as text files, they certainly can be. So I'd imagine it's just a matter of exposing those into files (or still classes and methods as separate "entities") and commit those into git with a bit of markup.
Didn't Smalltalk basically invent the idea of being able to open up objects at runtime? Even Objective-C, with its strong Smalltalk ties, allows for runtime modification.
Smalltalk is a family of dialects and implementations. Most of them are indeed compiled to bytecode which is then executed by a JIT VM. Most of them use the "image" concept where you are always in runtime like in a classic Lisp, and yes, the VM handles shape changes etc etc. But some Smalltalks actually have other characteristics, like non JIT or even compiling via C (Smalltalk/X does that I believe).
Smalltalk and Common Lisp are both image-based programming languages where the compiler and debugger are always available. I think debugger-oriented programming is much more common in Smalltalk than in Lisp (at least I prefer to leave the debugger back to REPL pretty often), but I think it's certainly possible to adopt. The Slime/Sly environments for emacs might accept a few patches to facilitate that programming style better.
> 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.
reply