It includes things like a source browser that allows looking up ways to deal with eg: email, if you have the/some source code, you can easily run it, a built in debugger and a tight write/test/fix-loop etc.
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.
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?
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-...
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.
Anyways, this an active research topic...see:
http://research.microsoft.com/pubs/211297/managedtime.pdf
If you haven't yet.
[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
See also: http://www.opencobalt.org/about/synchronization-architecture
"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 ]
"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/
i.e. live programming isn't programming. It's just a toy now.
> * storing code in a networked database with version control and realtime sync
This sounds a lot like Monticello and/or what Lively Kernel does over Webdav?
> * a structured editor to enable rich ASTs with unique UUIDs
I'd say something similar is achieved by Smalltalk with it's view that there is no "source code" -- there is only the compiled code that is also viewable/editable as text (this is not so much about code, but a feature of a truly object oriented system).
> * managing environments declaratively so that evaluating code is always safe
I don't see how "evaluating code" can "always" be safe? Or is this similar to having the ability to deploy a separate dev-image in Smalltalk terms?
> * a uniform (logical) data model where every piece of state is globally addressable
One example of this would be an object graph?
> * a model for change that tracks history and causality
I take it this is the "live programming" bit discussed alongside here. If all input and output is via messages, it would seem feasible to simply log messages (possibly collapse some messages (ie: +1, -1, +1, -1, +1 becomes just "+1").
> * a powerful query language that can be used for querying code, runtime state, causal graphs, profiling data etc
I'm not entirely convinced we need a "powerful" query language. But something to specify context (show me all counters in the date widget) would be good -- but it would be fine to express it as "in:someDateModule var:count". Maybe I just read "powerful query language" differently than the author (intended).
> * composable gui tools with transparent guts
We seem to be reinventing these forever.
> * a smooth interface to the old world so we don't end up sharing a grave with smalltalk
I really didn't want to go all "Smalltalk did that" (I'm not even sure it did I only know new-ish Smalltalks) -- but I think the eco-system is in the process of proving the death-by-different wrong: We use Apps on phones and through the web -- and the fact that eg: Google spreadsheets has pretty a pretty crappy interface with "the old world" doesn't seem to bother anyone. I mean, yeah, we know that we probably need to interface with some form of external file system -- but now we can pretty much just throw http/dav at the problem.
I guess I'm just grumpy -- arguably there's no difference between running a javascript vm on bare metal vs running a Smalltalk system on bare metal (except for the language part, but we can implement the language(s) we need on top of js anyway…). I just can't help but feel we might do better with a system better designed to be a system, rather than the web browser that accidentally became a vm and virtualized display driver. It doesn't strike me as likely that we'll see a proper security model that actually works for javascript in the near future, for example.
It's a shame that it's not being said more clearly and explicitly in the post; but that 'model for change' implies immutable/persistent data structures and all that comes along with that.
The foundational assumption that data is never deleted or updated but just garbage collected does really change a lot.
Essentially (I'm hoping!) they're just saying: let's build another Smalltalk but with persistent data structures and reactive programming instead of Smalltalk's MVC model.
But yeah; it does sound like they need to study the Smalltalk ecosystem a bit better to figure out that apart from those two things Smalltalk did already do pretty much everything they want to be doing here; or find a marketing angle that's less off putting to those that know Smalltalk well...