
Live Literate Programming [video] - mpweiher
https://www.youtube.com/watch?v=HW7sqMjTkI0&feature=youtu.be
======
brudgers
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}.

~~~
gbracha
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.

~~~
brudgers
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).

------
jostylr
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.

~~~
brudgers
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.

------
wonderous
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.

SOURCE:
[http://2017.programmingconference.org/event/programming-2017...](http://2017.programmingconference.org/event/programming-2017-keynotes-
live-literate-programming)

------
lucio
a TL;DR? with a video where the projected screen can be seen? a more on the
point demo?

~~~
gbracha
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.

~~~
gbracha
FWIW, I made some videos of the demos; these are linked to from
[https://gbracha.blogspot.com/2017/05/dead-programs-
society.h...](https://gbracha.blogspot.com/2017/05/dead-programs-society.html)

