Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

Most of what was Smalltalk has been adopted into modern IDEs (edit and continue, class browser, graphical debuggers, object-oriented programming). Now we are beginning to move beyond Smalltalk; e.g. Smalltalk never provided very powerful search facilities, real live programming, or speculative execution.

View on HN

How did Smalltalk not provide "real" live programming?

Change your code in smalltalk, say from "w color: black" to "w color: red". And even though the code of the program is "changed," nothing happens because the modified statement is not automatically re-executed. In a live programming system, you get useful feedback about your code edits, not just "fix and continue," and so you would immediately see affected widgets go from being black to red.

Chris Hancock's dissertation [1] is really good at making this point:

> And yet, if making a live programming environment were simply a matter of adding "continuous feedback," there would surely be many more live programming languages than we now have. As a thought experiment, imagine taking Logo (or Java, or BASIC, or LISP) as is, and attempting to build a live programming environment around it. Some parts of the problem are hard but solvable, e.g. keeping track of which pieces of code have been successfully parsed and are ready to run, and which ones haven’t. Others just don’t make sense: what does it mean for a line of Java or C, say a = a + 1, to start working as soon as I put it in? Perhaps I could test the line right away—many programming environments allow that. But the line doesn't make much sense in isolation, and in the context of the whole program, it probably isn't time to run it. In a sense, even if the programming environment is live, the code itself is not

i.e. Smalltalk code simply isn't live.

[1] http://llk.media.mit.edu/papers/ch-phd.pdf

Thanks for clarifying -- I'm still not sure which environments are much "more" live than Smalltalk. If you do make changes, usually that code will be executed on the next call?

Or are you talking about some strict old Smalltalk-80?

While you could change a parameter like color in some text-representation of the live code, wouldn't it be more natural (in Smalltalk) to simply change the object [ed: object instance] in question (and see the immediate change)?

I'm considering things like:

http://pharo.gforge.inria.fr/PBE1/PBE1ch7.html#x32-111006r22...

If Smalltalk allows editing values of variables of running code, and hot code loading -- what is missing? Is it the fact that other systems define the source code as "the truth", and consider the byte/compiled code to be a "secondary artefact" that causes (my) confusion?

Because as far as I can tell, Smalltalk does allow you to manipulate the objects that make up your system live?

Direct manipulation of the program's state (as opposed to writing/editing code that changes the state) is always live of course in any language. So ya, Smalltalk objects are "live", but Smalltalk code is not. So when Hancock invented this term called "live programming" back in 2003, he was focusing on the code (keep in mind, this work exists in a world where Smalltalk is well known, the Morphic paper came out in 1995, and Seymour Papert of Mindstorms/Logo fame is Hancock's adviser).

The problem with editing the program's objects directly is that it is not very powerful in its capability: fine if you want w to always be red, but not fine if their are a hundred w's to edit individually, or if w is red because of some kind of active condition. In any case, hot code replacement doesn't really help either; its useful for sure, but the next step is to change the program's state retroactively [1] to match the new code. Smalltalk never went there, and probably couldn't given the hardware constraints of the time. But now, I think we can go there.

The Pharo folks are claiming that their system supports live programming capabilities, but it is just the same old live object/fix-and-continue features that Smalltalk has had for ages. I suspect that they just really don't know what live programming means, and are latching onto the word because its "trendy."

[1] http://dynamicaspects.org/blog/2012/08/15/changing-the-past-...

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.

Anyways, this an active research topic...see:

http://research.microsoft.com/pubs/211297/managedtime.pdf

If you haven't yet.

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.

[1] http://www.opencobalt.org/about/history

[2] I think the paper I read is this one -- but I can't verify it from here:

"Designing croquet's TeaTime: a real-time, temporal environment for active object cooperation", David P. Reed http://dl.acm.org/citation.cfm?id=1094861

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.

An earlier paper by Reed also seems relevant:

"Implementing atomic actions on decentralized data" http://dl.acm.org/citation.cfm?id=357355

Again, the goal here is not live programming, but the "boxing" of blocks of code into "atomic actions" feels very similar to the MS paper.

[edit: Some interesting parallels with the earlier story on Soundcloud's Roshi system too https://news.ycombinator.com/item?id=7732696 ]

Thanks, I'll take a look! Look like I'm going to make many changes for the camera copy.

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.

The problem is: live programming does not scale and the very few examples are also not convincing.

i.e. live programming isn't programming. It's just a toy now.

It's a dream and a big risk. And I'm sure the destination will not be as envisioned, but we can finally make some real progress in interactive programming over Smalltalk/lisp.

Reply on news.ycombinator.com