add overview diagram

README.md

@@ -14,16 +14,50 @@ Many programmers love the REPL (aka Interactive Shell, Notebook, Playgrounds).
 
 It provides validation, useful feedback, it's very useful for learning to code, and in some cases it even produces the actual program results (obviating the need to build a full application).
 
-But the REPL often loses its efficacy when writing larger programs, to the point that many "serious" programming languages such Java, Rust, and C++ don't even bother offering one.
+But the REPL often loses its efficacy when writing larger programs, to the point that many "serious" programming languages such Go, Rust, and C++ don't even bother offering one. Until recently did Java and C# were also on that list.
 
 ### How the REPL loses efficacy for larger programs
 
-How exactly does the REPL become less effective for large programs?
+We identify three problems with scaling the REPL for large statically typed programs:
 
-We recognize two problems:
-
-* Availability
 * Bandwidth
+* Liveness
+* Availability
+
+#### Bandwidth
+
+(Showing in the background factorial with a bug in Python)
+
+The REPL only displays the final result of the computation.
+This doesn't provide much insight into the inner working of the code.
+
+When writing large programs, one would typically be editing their modules for longer periods between invoking the REPL,
+resulting in less feedback from the REPL the larger their programs are.
+
+This situation is like trying to understand a large mechanism with many moving parts
+by only looking at it through a tiny peep-hole.
+
+Display a peep-hole view of something.
+Programmers use tools like the debugger to move the peep-hole, but it is a klunky experience.
+Display the peep-hole moving.
+
+We're going to demonstrate how it looks like in Lamdu, but first, let's familiarize ourselves with its syntax.
+(explain syntax elements for the factorial function)
+
+Show the value annotations in factorial in Lamdu.
+
+Show the peep-hole again but reveal the full picture.
+
+#### Liveness
+
+The liveness problem is that there often is a discrepency between the edited code and the feedback from the REPL.
+The easy way to solve this discrepency is via live-reloading.
+But this may cause a new problem - Safety.
+We'll demonstrate this problem using Swift.
+
+The programmer fixes a compilation error, but due to a mind burp enters "!=" rather than "==".
+Swift automatically runs the code, which triggers a call to the "launchNukes" procedure,
+bringing upon the end of the world as we know it.
 
 #### Availability
 

scenes/diagram.dot

@@ -0,0 +1,34 @@
+digraph {
+    ratio=0.5625
+    node [fillcolor="#dddddd" style=filled]
+
+    main [label="Scaling the REPL Experience"]
+
+    annotations [label="Subexpression\nAnnotations"]
+    live [label="Live\nReloading"]
+    Purity
+    projectional [label="Projectional\nEditing"]
+    blame [label="Type\nError\nLocality"]
+    WYTIWYS
+
+    node [shape=doubleoctagon fillcolor=red fontcolor=white]
+
+    Bandwidth
+    Liveness
+    Availability
+    Safety
+    UI
+
+    main -> Bandwidth
+    main -> Liveness
+    main -> Availability
+
+    Bandwidth -> annotations
+    Liveness -> live
+    live -> Safety
+    Safety -> Purity
+    Availability -> projectional
+    Availability -> blame
+    projectional -> UI
+    UI -> WYTIWYS
+}

scenes/haskell-examples.hs

@@ -0,0 +1,15 @@
+import Control.Lens.Operators
+import Prelude
+
+
+
+fibonacci :: [Integer]
+fibonacci =
+    iterate step (1, 0)
+    <&> fst
+    where
+        step (cur, prev) = (cur+prev, cur)
+
+
+>>> take 10 fibonacci
+[1,1,2,3,5,8,13,21,34,55]