For me, it seems that liveness and literacy are in some tension because liveness allows acting without the intent of producing a document and literacy facilitates an intent to produce a document.
I think the tension may revolve around scope. For example, liveness allowing a document's text to be translated from Hebrew to English seems more likely to be consistent with the an author's intent. Liveness that allows changing "In the beginning" to "Check out my new website" seems less likely to be so. The tension is that the scope of liveness which is appropriate in a particular case will vary. An author may want to allow the transformation to "check out my new website" but not "The future is already here."
In a truly live system, the rules for what is and isn't alive would also be alive. It's turtles all the way down...until you get to StackOverflow or something something static. The tension, at least for me is that the system has to decide where the liveness stops and like abstractions, adding one more layer of liveness is always attractive to a systems architect.
The alternative where liveness is added by the author and things default to dead may be better for many use cases and perhaps what is needed are better tools for adding liveness. Some of the use cases I am thinking about are situations in the same class as an Excel spreadsheet executing malware. Part of what makes this plausible to me is that this --interactivity enabled explicitly by the intersection of author and reader permissions -- is the way Emacs org-mode works. And org-mode is relevant to this particular video because it was used to prepare the interactive presentation {mentioned somewhere between 40:00-45:00 in the video}.
I agree that there are times where you want to nail things down so they cannot be changed. It's just that it's easier to restrict the behavior of a live system than to customize a "dead" one. Hence liveness needs to be at the foundation.
I had not yet listened to the QA portion of the talk when I wrote my comment, so maybe I did not entirely account for how much my take might have been a response to what was said for effect...and now I have also had a bit of time away from my comment to think a bit more.
Openness may be a third axis that relates the design of platforms/systems intended for liveness and literacy. A sketch of contrasting approaches to openness might be between Emacs and a traditional Smalltalk IDE. Emacs is open in the sense that the designers designed the tool around user customization and extension. Smalltalk IDE's tend not to have that as a first order design principle. Over the long haul (openness in Smalltalk seems to happen at a different layer of abstraction). I think it may be more practical to add liveness to a programming tool with openness as a primary design goal than openness to a programming tool with liveness as a primary design goal (with the premise that openness is not also a primary design goal of a particular programming tool).
I found the video did describe live programming quite a bit, but it was not clear to me how this was a merger with literate programming.
In my journey into literate programming, a large portion of its benefits is being able to sculpt the story into a well-ordered fashion that works for humans. That is, I think of it as a path of stepping through the plan and into the details.
In the talk, it seemed that the live portions would start with editing various final details with perhaps a literate description of the widget, but the widget's relation to other stuff seemed to be less present. This would be more like going up from the details and maybe up into a plan, a direction which I feel is rather typical non-literate programming.
I do think that live programming is useful in literate programming, particularly in more stylistic choices (such as choosing font-sizes if programming up a document display system) and simply making the check of working speedier.
What could be an interesting intersection of the live widget editing is if in editing a widget, the whole design hierarchy leading to that widget became visually available. In similar fashion, the widgets being in a hierarchy already would naturally create a placement for a new widget, encouraging higher level explanation of the widgets in the appropriate human story place while allowing for spur of the moment changes and additions.
The biggest danger in literate programming is the same danger as in other programming styles: modifying the plan in mid-coding and not sufficiently documenting that.
There were some explicit examples early in the talk: the mention of Java Applets in web documents and the creation of inline buttons in StrongTalk. The discussion of WYSIWYG a bit further along seems somewhat related to the intersection of literate programming and interaction.
My sense is Bracha's presentation asymptotes toward literate programming more from the programmer side versus from a starting point writing prose. My utterly unsubstantiated suspicion is that Knuth's asymptote was more from the direction of writing prose since a substantial proportion of the code he writes seems to be to be to support his prose writing habit...or to put it another way, Knuth seems to have a strong sense of self-identity as a writer as well as a programmer. But I could be wrong on both counts.
Or to put it another way, one concept (among many valid concepts) of literate programming might be literate programming as writing about code with the intent that all the examples run as a meaningful program or library. That is as an extension of writing an article or book about programming. That's a bit different connotativel y from approaching literate programming as a different way of writing programs or libraries...even if the end artifacts of a prose document and source file(s) are logically similar.
Abstract: Literate programming was conceived by Donald Knuth in the 1970s. Live programming has its roots even earlier, but the classic examples date from that same time. Both live programming and literate programming are now experiencing a resurgence. While these ideas were introduced separately, the two were made for each other from the start. This talk celebrates their happy, literate and live marriage.
Bio: Gilad Bracha is the creator of the Newspeak programming language and a software engineer at Google where he works on Dart. Previously, he was a VP at SAP Labs, a Distinguished Engineer at Cadence, and a Computational Theologist and Distinguished Engineer at Sun. He is co-author of the Java Language Specification, and a researcher in the area of object-oriented programming languages. Prior to joining Sun, he worked on Strongtalk, the Animorphic Smalltalk System. He received his B.Sc in Mathematics and Computer Science from Ben Gurion University in Israel and a Ph.D. in Computer Science from the University of Utah.
I'm very sorry that the recording doesn't show the screen properly. Especially for this talk, where the demos are crucial. I may have to recreate the talk as a screencast.
I think the tension may revolve around scope. For example, liveness allowing a document's text to be translated from Hebrew to English seems more likely to be consistent with the an author's intent. Liveness that allows changing "In the beginning" to "Check out my new website" seems less likely to be so. The tension is that the scope of liveness which is appropriate in a particular case will vary. An author may want to allow the transformation to "check out my new website" but not "The future is already here."
In a truly live system, the rules for what is and isn't alive would also be alive. It's turtles all the way down...until you get to StackOverflow or something something static. The tension, at least for me is that the system has to decide where the liveness stops and like abstractions, adding one more layer of liveness is always attractive to a systems architect.
The alternative where liveness is added by the author and things default to dead may be better for many use cases and perhaps what is needed are better tools for adding liveness. Some of the use cases I am thinking about are situations in the same class as an Excel spreadsheet executing malware. Part of what makes this plausible to me is that this --interactivity enabled explicitly by the intersection of author and reader permissions -- is the way Emacs org-mode works. And org-mode is relevant to this particular video because it was used to prepare the interactive presentation {mentioned somewhere between 40:00-45:00 in the video}.