Hm. I still think it's a rather thin distinction, and one more concerned with what programs, data and objects are (and their relation to source code), more than with what is possible in Smalltalk.
If we look at what is possible, namely changing data and instructions in ram -- it seems to me that Smalltalk already provides that.
I suppose there is some value to viewing a program as a kind of differential equation over time (where we assume the future has not yet happened, and all input has been given at certain points in time) -- and so be able to change the state at a given present, by changing the program, and accounting for how that change would translate to a different state in the present, given the same inputs... But we cannot stop time, nor the real world -- so most real systems can only be approximated in this way.
The best we can do (with any real system that isn't isolated from the outside) is to take a snapshot at a given time t, make changes to see how that state could have been at t with our new code -- but we then would have to bring our system back into the present -- either by playing back recorded input or by some other means...
I don't think your points about w manage to put weight behind (or communicate) your point: in Smalltalk you could either programaticaly alter all ws, or if you changed the condition on which w depended, all ws would update (in a GUI, or other system with an event loop...). I get that that's not your point though.
The distinction is massive, and why all those Bret Victor demos have nothing to do with Smalltalk. You can record a bit of your program's execution during development.
Interesting, hadn't seen that (have to read it in more detail later). Does sort of remind me of the approach taken to synchronization/managing time for Croquet[1]: Tea time[2] (although the aim there had nothing to do with live programming). Seems like a different need for managing time, but a not entirely dissimilar approach.
Thank you for the references. I've seen some of these before, but connecting the dots can be difficult (meaning, I have to keep going back to them later). A lot of seems to have gone into Kay's new project @ VRPI.
Somewhat tangential (again thanks for the link, and the comments on "live programming"):
"In the Smalltalk model, for instance, state is persistent and code changes don't affect data. In the Clojure model, code is "mostly functional", with a small amount of carefully-managed state. Either model could be a starting point for a system where continuous code changes can be seen as continuous effects."
-- Bret Victor
http://worrydream.com/LearnableProgramming/
Right, but no one knows yet which will work (my hunch is a combination). My point was that the experiences he showed weren't Smalltalk experiences; we have finally got a lot of great ideas what to do post smalltalk.
If we look at what is possible, namely changing data and instructions in ram -- it seems to me that Smalltalk already provides that.
I suppose there is some value to viewing a program as a kind of differential equation over time (where we assume the future has not yet happened, and all input has been given at certain points in time) -- and so be able to change the state at a given present, by changing the program, and accounting for how that change would translate to a different state in the present, given the same inputs... But we cannot stop time, nor the real world -- so most real systems can only be approximated in this way.
The best we can do (with any real system that isn't isolated from the outside) is to take a snapshot at a given time t, make changes to see how that state could have been at t with our new code -- but we then would have to bring our system back into the present -- either by playing back recorded input or by some other means...
I don't think your points about w manage to put weight behind (or communicate) your point: in Smalltalk you could either programaticaly alter all ws, or if you changed the condition on which w depended, all ws would update (in a GUI, or other system with an event loop...). I get that that's not your point though.