More than (almost) any other language/environment, Smalltalk is capable of this kind of 'liveness'. That it hasn't been implemented in the way you refer is due more to a lack of development effort than anything else.
For the last four decades, Smalltalk has been providing a glimpse of the future. That future is still waiting to happen.
That's a vacuous statement if I've ever heard one. Nothing in Smalltalk makes achieving liveness easier than say Java or, more obviously, a language with very encapsulated state like Erlang, and definitely not various visual languages where you get liveness for free (Quartz Composer!). It's telling that Granger et al are basing Light Table on Clojure/Lisp rather than Smalltalk (it will be interesting to see what Bracha does with Newspeak, however). Also consider various game editing engines (Unreal, Unity) that offer live scene scripting capabilities in whatever scripting language and C++ they support.
Smalltalk was crazy innovative, while Self (Smalltalk's only real successor) gave us the first live graphics toolkit (Morphic). But the future is still being invented, and it will be a much better experience than Smalltalk ever was.
Smalltalk is capable of evaluating statements as they're entered, and it's a relatively small step to reflect those changes immediately on compilation - thus, 'liveness', as in Light Table. I can't imagine being able to do that in Java.
If I'm missing something, can you please provide some more detail?
Liveness is an experience, hotswapping is a mechanism that gets you 5% of the way their. Its like saying "we've done 5% of the work ,the rest of the 95% should be easy right?" Actually, just figuring out what the experience is difficult. So more details...
Hancock defines the term "live programming" in his thesis [1] and its where I get my definition from (before Hancock, the term doesn't exist, though liveness was defined by Tanimoto and Maloney in the 90s). Basically, live programming is about continuous feedback for which hot swapping might be useful (though it must be said its not exactly necessary nor is it sufficient). But there is much more to it: you want continuous feedback about the code you are editing, not just some idea that the code will run sometime in the future in a running program. You want to also observe the behavior of this code in a way that is comprehensible, and map this behavior back to your code.
I wrote and presented a paper [2] on live programming back in 2007. Ralph Johnson (a big Smalltalker) was in my audience and had the same complaint: he only saw hot swapping and not the experience I was presenting. To him, it was mechanism, not exeperience. I wonder if this is a problem with Smalltalkers in general.
I understand the difference between 'hot-swapping' and 'liveness'. However (admittedly, I may be mistaken) I believe the Smalltalk architecture already has the requisite functionality (eval and reflection - just like Lisp) to support this, although no one's actually implemented it yet. (And it ought to be more straightforward than building it in a Lisp-to-Javascript compiler on top of a Lisp on top of the JVM!)
Any Turing-complete language has the requisite functionality to support liveness, but something like Time Warp support by the OS/VM would make it easier. But honestly, at this point, even designing the experience (vs. implementing it) is hard enough, and we owe a lot to Bret Victor's talk here. Hancock's thesis sets high standards on how the feedback must be comprehensible (as opposed to some random lights flashing on and off).
I wrote a lengthy post in the history article you linked to. Its just not the live programming history that I'm familiar with, they seem to be falling into the same smalltalk mechanism trap that I was talking about in this thread.
For the last four decades, Smalltalk has been providing a glimpse of the future. That future is still waiting to happen.