From 4f8db4f83a48a0521d86d36e8b74bb47bb10f5ea Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Tue, 5 Nov 2019 23:59:04 -0500
Subject: [PATCH 01/12] first draft

---
 src/debugging.bib        | 175 +++++++++++++++++++++++++++++++++++
 src/live-programming.rst | 194 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 369 insertions(+)
 create mode 100644 src/debugging.bib

diff --git a/src/debugging.bib b/src/debugging.bib
new file mode 100644
index 0000000..d27cd1d
--- /dev/null
+++ b/src/debugging.bib
@@ -0,0 +1,175 @@
+@article{lawrance2013foraging,
+ author = {Lawrance, Joseph and Bogart, Christopher and Burnett, Margaret and Bellamy, Rachel and Rector, Kyle and Fleming, Scott D.},
+ title = {How Programmers Debug, Revisited: An Information Foraging Theory Perspective},
+ journal = {IEEE Trans. Softw. Eng.},
+ issue_date = {February 2013},
+ volume = {39},
+ number = {2},
+ month = feb,
+ year = {2013},
+ issn = {0098-5589},
+ pages = {197--215},
+ numpages = {19},
+ url = {https://doi.org/10.1109/TSE.2010.111},
+ doi = {10.1109/TSE.2010.111},
+ acmid = {2478703},
+ publisher = {IEEE Press},
+ address = {Piscataway, NJ, USA},
+ keywords = {Approximation methods, Debugging, Information foraging theory, Navigation, Predictive models, Programming environments, Topology, debugging, empirical software engineering, information scent, programmer navigation, software maintenance},
+}
+
+@article{ko2005framework,
+ author = {Ko, Andrew J. and Myers, Brad A.},
+ title = {A Framework and Methodology for Studying the Causes of Software Errors in Programming Systems},
+ journal = {J. Vis. Lang. Comput.},
+ issue_date = {February, 2005},
+ volume = {16},
+ number = {1-2},
+ month = feb,
+ year = {2005},
+ issn = {1045-926X},
+ pages = {41--84},
+ numpages = {44},
+ url = {http://dx.doi.org/10.1016/j.jvlc.2004.08.003},
+ doi = {10.1016/j.jvlc.2004.08.003},
+ acmid = {1747434},
+ publisher = {Academic Press, Inc.},
+ address = {Orlando, FL, USA},
+}
+
+@inproceedings{latoza2010reachability,
+ author = {LaToza, Thomas D. and Myers, Brad A.},
+ title = {Developers Ask Reachability Questions},
+ booktitle = {Proceedings of the 32Nd ACM/IEEE International Conference on Software Engineering - Volume 1},
+ series = {ICSE '10},
+ year = {2010},
+ isbn = {978-1-60558-719-6},
+ location = {Cape Town, South Africa},
+ pages = {185--194},
+ numpages = {10},
+ url = {http://doi.acm.org/10.1145/1806799.1806829},
+ doi = {10.1145/1806799.1806829},
+ acmid = {1806829},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {code navigation, developer questions, empirical study, program comprehension, software maintenance},
+}
+
+@article{caballero2017survey,
+author = {Caballero, Rafael and Riesco, Adrián and Silva, Josep},
+year = {2017},
+month = {08},
+pages = {1-35},
+title = {A Survey of Algorithmic Debugging},
+volume = {50},
+journal = {ACM Computing Surveys},
+doi = {10.1145/3106740}
+}
+
+@article{nilsson1994lazy,
+author={Nilsson, Henrik and Fritzson, Peter},
+title={Algorithmic debugging for lazy functional languages},
+volume={4}, DOI={10.1017/S095679680000109X},
+number={3},
+journal={Journal of Functional Programming},
+publisher={Cambridge University Press},
+year={1994},
+pages={337–369}
+}
+
+@inproceedings{perera2012explain,
+ author = {Perera, Roly and Acar, Umut A. and Cheney, James and Levy, Paul Blain},
+ title = {Functional Programs That Explain Their Work},
+ booktitle = {Proceedings of the 17th ACM SIGPLAN International Conference on Functional Programming},
+ series = {ICFP '12},
+ year = {2012},
+ isbn = {978-1-4503-1054-3},
+ location = {Copenhagen, Denmark},
+ pages = {365--376},
+ numpages = {12},
+ url = {http://doi.acm.org/10.1145/2364527.2364579},
+ doi = {10.1145/2364527.2364579},
+ acmid = {2364579},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {debugging, program slicing, provenance},
+}
+
+@inproceedings{weiser1981slicing,
+ author = {Weiser, Mark},
+ title = {Program Slicing},
+ booktitle = {Proceedings of the 5th International Conference on Software Engineering},
+ series = {ICSE '81},
+ year = {1981},
+ isbn = {0-89791-146-6},
+ location = {San Diego, California, USA},
+ pages = {439--449},
+ numpages = {11},
+ url = {http://dl.acm.org/citation.cfm?id=800078.802557},
+ acmid = {802557},
+ publisher = {IEEE Press},
+ address = {Piscataway, NJ, USA},
+ keywords = {Data flow analysis, Debugging, Human factors, Program maintenance, Program metrics, Software tools},
+}
+
+@inproceedings{ko2008whyline,
+ author = {Ko, Andrew J. and Myers, Brad A.},
+ title = {Debugging Reinvented: Asking and Answering Why and Why Not Questions About Program Behavior},
+ booktitle = {Proceedings of the 30th International Conference on Software Engineering},
+ series = {ICSE '08},
+ year = {2008},
+ isbn = {978-1-60558-079-1},
+ location = {Leipzig, Germany},
+ pages = {301--310},
+ numpages = {10},
+ url = {http://doi.acm.org/10.1145/1368088.1368130},
+ doi = {10.1145/1368088.1368130},
+ acmid = {1368130},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {whyline},
+}
+
+@inproceedings{silva2006adps,
+ author = {Silva, Josep and Chitil, Olaf},
+ title = {Combining Algorithmic Debugging and Program Slicing},
+ booktitle = {Proceedings of the 8th ACM SIGPLAN International Conference on Principles and Practice of Declarative Programming},
+ series = {PPDP '06},
+ year = {2006},
+ isbn = {1-59593-388-3},
+ location = {Venice, Italy},
+ pages = {157--166},
+ numpages = {10},
+ url = {http://doi.acm.org/10.1145/1140335.1140355},
+ doi = {10.1145/1140335.1140355},
+ acmid = {1140355},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {algorithmic debugging, program slicing},
+}
+
+@INPROCEEDINGS{latoza2011reacher,
+author={T. D. {LaToza} and B. A. {Myers}},
+booktitle={2011 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC)},
+title={Visualizing call graphs},
+year={2011},
+volume={},
+number={},
+pages={117-124},
+keywords={program debugging;program visualisation;reverse engineering;interactive call graph visualization;REACHER;program visualization;program comprehension;control flow;Visualization;Navigation;Context;Joining processes;Debugging;Vegetation;Upper bound;code exploration;call graphs;control flow;program visualization;program comprehension},
+doi={10.1109/VLHCC.2011.6070388},
+ISSN={},
+month={Sep.},}
+
+@ARTICLE{araki1991framework,
+author={K. {Araki} and Z. {Furukawa} and J. {Cheng}},
+journal={IEEE Software},
+title={A general framework for debugging},
+year={1991},
+volume={8},
+number={3},
+pages={14-20},
+keywords={program debugging;programming;supervisory programs;debugged process model;general debugging framework;traditional debugging processes;support tools;debugging methodologies;execution monitor;Eden;Programming profession;Error correction;Logic;Probes;Software debugging;Software tools;Computer industry;Computer bugs;History;Graphics},
+doi={10.1109/52.88939},
+ISSN={},
+month={May},}
diff --git a/src/live-programming.rst b/src/live-programming.rst
index 4c8877a..627dbb5 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -20,9 +20,203 @@ Data Analysis Environments
 Debugging
 =========
 
+  "The EDSAC was on the top floor of the building and the tape-punching
+  and editing equipment one floor below... It was on one of my journeys
+  between the EDSAC room and the punching equipment that...the realization
+  came over me with full force that a good part of the remainder of my
+  life was going to be spent in finding errors in my own programs."
+
+  -- *Memoirs of a Computer Pioneer*, Maurice Wilkes
+
+Much of the activity of programming involves **debugging**, i.e.,
+diagnosing and preventing undesired program behavior.
+Wilkes's early realization of this fact was echoed and amplified in a 2002
+study of the U.S. software industry, which found that software engineers
+spent an average of 70-80% of their time testing and debugging, with
+the average bug taking 17.4 hours to fix.
+Thus, debuggers form a crucial component of an effective programming system.
+(needs better finish)
+
+Software bugs manifest at three levels. Typically a bug is first
+observed as a **runtime failure**, an instance of external program
+behavior that does not comply with the intended design. Underlying
+the runtime failure are **runtime faults**, aberrations
+in machine or program state (e.g., a wrong value in a CPU register,
+an uninitialized object) that lead to the noncompliant behavior.
+Finally, causing the runtime faults are the **software errors** in
+the source code.
+
+Using these terms, debugging may be understood
+more precisely as the collective processes of determining what runtime
+faults led to a runtime failure, determining what software errors
+led to those faults, and modifying the code to prevent the faults from
+occurring. A **debugger** is a tool that allows the programmer to observe
+the machine state during program execution, thereby making it possible to
+identify runtime faults.
+
+Theories of Human Debugging
+---------------------------
+
+Debugging is a complex activity. Recent work develops frameworks and
+theories for understanding the cognitive processes underlying
+programmer errors and debugging strategies, and the ways that
+debugging interfaces influence those processes.
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'ko2005framework'
+
+  Noting the inadequacy of existing HCI frameworks at the time
+  for analyzing error-prone processes like programming, this paper
+  proposed a framework and methodology for analyzing and designing
+  programming systems that focuses specifically on software errors.
+  The framework deconstructs the various cognitive breakdowns that may
+  occur throughout software development and characterizes software
+  errors in terms of the *chains of cognitive breakdowns* that lead to
+  them. (add another sentence about analysis of Alice and Whyline)
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'latoza2010reachability'
+
+  This paper introduced the concept and formalism of
+  *reachability questions*: searches across feasible paths through a
+  program for target statements matching search criteria.
+  (add another sentence about user studies and prevalence of reachability questions)
+
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'lawrance2013foraging'
+
+  This paper provided a theory of programmer navigation when debugging
+  based on information foraging theory.
+  (add sentence elaborating on connection to ift)
+  (add sentence about user study)
+  (add sentence about providing first principled design guidelines for making interactive debuggers)
+
+
+
 Interactive Debuggers
 ---------------------
 
+describe history of transition from physical computing
+systems to observing core dumps
+to more interactive stepping and navigation, graphical
+projections of execution behavior onto source code, etc
+
+Interactive Breakpoints
+^^^^^^^^^^^^^^^^^^^^^^^
+.. todo::
+  bibliography on breakpoints
+
+Time-Travel Debugging
+^^^^^^^^^^^^^^^^^^^^^
+.. todo::
+  bibliography on time-travel debugging,
+  distinguishing between record-replay and
+  reversible/omniscient debugging
+
+Program Slicing
+^^^^^^^^^^^^^^^
+
+(add description of program slicing as decomposition of programs)
+(provide some overview of different types of program slicing, e.g., static vs dynamic)
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'weiser1981slicing'
+
+  This paper introduced program slicing.
+  (add details about static slices)
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'ko2008whyline'
+
+  (describe connection to earlier work on debugging theory)
+  (describe the tool and how it uses dynamic program slicing)
+  (describe user study and result)
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'latoza2011reacher'
+
+  (describe connection to earlier work on reachability questions)
+  (describe the tool)
+  (describe user study and results)
+  (should probably move this out of program slicing)
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'perera2012explain'
+
+  (static and dynamic program slicing for functional programs)
+  (no implementation or evaluation)
+
+
+Algorithmic Debugging
+^^^^^^^^^^^^^^^^^^^^^
+
+*Algorithmic debugging* (also called *declarative debugging*) is a semi-automatic
+debugging technique in which the debugger automatically generates a series of
+questions to which the programmer's answers guide the search toward the bug.
+The debugger constructs an *execution tree* (ET), a data structure representing a
+program execution, and traverses it using some search strategy, asking the
+programmer at each ET node whether the represented subcomputation is correct
+in order to determine the next step.
+This technique guarantees that, if the programmer answers all the questions correctly,
+the bug will eventually be found.
+
+Although algorithmic debugging can be applied in any language paradigm, it is most
+suited for declarative languages, e.g., pure functional languages.
+to determine whether an ET node for a pure functional program is correct, the
+programmer need only check that the return value of the corresponding, referentially
+transparent expression is the expected one, independent of any other ET node.
+On the other hand, checking the correctness of an ET node for an imperative program
+requires checking, in addition to the return value, that values in the heap have
+been updated correctly---this can be difficult to ascertain because the programmer
+must maintain an understanding of how any *subsequent ET node* depends on those updated
+values.
+
+Despite their useful guarantee of bug diagnosis, algorithmic debuggers have yet to enter
+widespread use. (add note about functional programming research lagging in tooling)
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'nilsson1994lazy'
+
+  This paper introduced the use of algorithmic debugging---originally developed
+  for logic programs---for debugging lazy functional programs. (add sentence about
+  how algorithmic debugging is useful when evaluation order doesn't matter)
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'silva2006adps'
+
+  This paper noted the complementary strengths of program slicing and algorithmic
+  debugging and unified them in a common theoretical framework.
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'caballero2017survey'
+
+  This paper surveys the state-of-the-art in algorithmic debugging
+  (add some example observations)
+  (add observation about algorithmic debugging still not reaching mature
+  implementations or wide audiences)
+
+
 Program Visualization
 ---------------------
 

From d5d137131c27e0a537a14989ac8a0cdc2647f756 Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Thu, 14 Nov 2019 22:16:04 -0500
Subject: [PATCH 02/12] Write bib item entry for AD survey

---
 src/live-programming.rst | 26 ++++++++++++++++++++------
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/src/live-programming.rst b/src/live-programming.rst
index 627dbb5..82d29f7 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -177,7 +177,7 @@ the bug will eventually be found.
 
 Although algorithmic debugging can be applied in any language paradigm, it is most
 suited for declarative languages, e.g., pure functional languages.
-to determine whether an ET node for a pure functional program is correct, the
+To determine whether an ET node for a pure functional program is correct, the
 programmer need only check that the return value of the corresponding, referentially
 transparent expression is the expected one, independent of any other ET node.
 On the other hand, checking the correctness of an ET node for an imperative program
@@ -211,11 +211,25 @@ widespread use. (add note about functional programming research lagging in tooli
   .. bibliography:: debugging.bib
     :filter: key == 'caballero2017survey'
 
-  This paper surveys the state-of-the-art in algorithmic debugging
-  (add some example observations)
-  (add observation about algorithmic debugging still not reaching mature
-  implementations or wide audiences)
-
+  This paper surveyed the state-of-the-art in AD in
+  2017, 35 years since the technique's conception.
+  Motivating this survey was the authors' observation that, despite the many
+  useful properties of AD, the technique has yet to be
+  realized in a mature tool used in industry.
+
+  In the first half, the survey reviews the general principles of AD and
+  discusses the adaptation of these principles to various programming paradigms,
+  including logic, functional, imperative, and object-oriented programming.
+
+  In the second half, it takes a critical view and enumerates the historical
+  issues that have prevented widespread adoption of AD.
+  In addition to resource scalability challenges, it notes several issues
+  with the user experience of AD, including inflexible navigation of the
+  debugging tree and difficult-to-answer generated questions.
+  It then reviews a variety of proposed solutions to many of these issues,
+  but also notes in a review of existing implementations that current
+  tools remain largely sequestered within academia and do not integrate
+  many existing solutions.
 
 Program Visualization
 ---------------------

From d2367b7b2426b3ba54d837db7bba09e86755ef56 Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Tue, 19 Nov 2019 08:54:04 -0500
Subject: [PATCH 03/12] Create Reachability Questions section

---
 src/live-programming.rst | 45 ++++++++++++++++++++--------------------
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/src/live-programming.rst b/src/live-programming.rst
index 82d29f7..cb792db 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -76,17 +76,6 @@ debugging interfaces influence those processes.
   errors in terms of the *chains of cognitive breakdowns* that lead to
   them. (add another sentence about analysis of Alice and Whyline)
 
-.. container:: bib-item
-
-  .. bibliography:: debugging.bib
-    :filter: key == 'latoza2010reachability'
-
-  This paper introduced the concept and formalism of
-  *reachability questions*: searches across feasible paths through a
-  program for target statements matching search criteria.
-  (add another sentence about user studies and prevalence of reachability questions)
-
-
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
@@ -143,6 +132,27 @@ Program Slicing
   (describe the tool and how it uses dynamic program slicing)
   (describe user study and result)
 
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'perera2012explain'
+
+  (static and dynamic program slicing for functional programs)
+  (no implementation or evaluation)
+
+Reachability Questions
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'latoza2010reachability'
+
+  This paper introduced the concept and formalism of
+  *reachability questions*: searches across feasible paths through a
+  program for target statements matching search criteria.
+  (add another sentence about user studies and prevalence of reachability questions)
+
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
@@ -153,13 +163,6 @@ Program Slicing
   (describe user study and results)
   (should probably move this out of program slicing)
 
-.. container:: bib-item
-
-  .. bibliography:: debugging.bib
-    :filter: key == 'perera2012explain'
-
-  (static and dynamic program slicing for functional programs)
-  (no implementation or evaluation)
 
 
 Algorithmic Debugging
@@ -216,20 +219,18 @@ widespread use. (add note about functional programming research lagging in tooli
   Motivating this survey was the authors' observation that, despite the many
   useful properties of AD, the technique has yet to be
   realized in a mature tool used in industry.
-
   In the first half, the survey reviews the general principles of AD and
   discusses the adaptation of these principles to various programming paradigms,
   including logic, functional, imperative, and object-oriented programming.
-
   In the second half, it takes a critical view and enumerates the historical
   issues that have prevented widespread adoption of AD.
-  In addition to resource scalability challenges, it notes several issues
+  It notes, in addition to resource scalability challenges, several issues
   with the user experience of AD, including inflexible navigation of the
   debugging tree and difficult-to-answer generated questions.
   It then reviews a variety of proposed solutions to many of these issues,
   but also notes in a review of existing implementations that current
   tools remain largely sequestered within academia and do not integrate
-  many existing solutions.
+  many known solutions.
 
 Program Visualization
 ---------------------

From 0a410f7bd5e2c87226e7e0e5e5bdb45fdc32ff57 Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Tue, 19 Nov 2019 23:35:54 -0500
Subject: [PATCH 04/12] Second draft

---
 src/debugging.bib        |  28 ++++++
 src/live-programming.rst | 179 +++++++++++++++++++++++++++++++--------
 2 files changed, 174 insertions(+), 33 deletions(-)

diff --git a/src/debugging.bib b/src/debugging.bib
index d27cd1d..e35cf46 100644
--- a/src/debugging.bib
+++ b/src/debugging.bib
@@ -112,6 +112,24 @@ @inproceedings{weiser1981slicing
  keywords = {Data flow analysis, Debugging, Human factors, Program maintenance, Program metrics, Software tools},
 }
 
+@inproceedings{ko2004whyline,
+ author = {Ko, Andrew J. and Myers, Brad A.},
+ title = {Designing the Whyline: A Debugging Interface for Asking Questions About Program Behavior},
+ booktitle = {Proceedings of the SIGCHI Conference on Human Factors in Computing Systems},
+ series = {CHI '04},
+ year = {2004},
+ isbn = {1-58113-702-8},
+ location = {Vienna, Austria},
+ pages = {151--158},
+ numpages = {8},
+ url = {http://doi.acm.org/10.1145/985692.985712},
+ doi = {10.1145/985692.985712},
+ acmid = {985712},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {Alice, debugging, program slicing},
+}
+
 @inproceedings{ko2008whyline,
  author = {Ko, Andrew J. and Myers, Brad A.},
  title = {Debugging Reinvented: Asking and Answering Why and Why Not Questions About Program Behavior},
@@ -173,3 +191,13 @@ @ARTICLE{araki1991framework
 doi={10.1109/52.88939},
 ISSN={},
 month={May},}
+
+@inbook{sjoberg2008building,
+author = {Sjøberg, Dag and Dybå, Tore and Anda, Bente and Hannay, Jo},
+year = {2008},
+month = {01},
+pages = {312-336},
+title = {Building Theories in Software Engineering},
+journal = {Guide to Advanced Empirical Software Engineering},
+doi = {10.1007/978-1-84800-044-5_12}
+}
diff --git a/src/live-programming.rst b/src/live-programming.rst
index cb792db..4d9bf3e 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -74,28 +74,51 @@ debugging interfaces influence those processes.
   The framework deconstructs the various cognitive breakdowns that may
   occur throughout software development and characterizes software
   errors in terms of the *chains of cognitive breakdowns* that lead to
-  them. (add another sentence about analysis of Alice and Whyline)
+  them. Cognitive breakdowns are characterized, in turn, by their breakdown type,
+  the action being performed by the programmer, the interface being
+  used to perform the action, and the information being acted upon.
+  For example, an interruption may cause a programmer to experience
+  an inattention breakdown upon creating a loop header in their program
+  editor and forget to include the closing brace, introducing a syntax
+  error.
+  The paper described the application of this methodology to
+  evaluate the Alice programming environment by coding and quantifying
+  users' common breakdown chains.
+  The use of this framework directly inspired the design of new programming
+  tools such as the Whyline :cite:`ko2008whyline`.
 
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
     :filter: key == 'lawrance2013foraging'
 
-  This paper provided a theory of programmer navigation when debugging
+  Prior to this paper, theories of debugging relied on complex
+  mental constructs and were
+  mostly developed in an age in which programming environments were
+  relatively simple. These theories did not take into account the substantial
+  navigational activities performed in modern IDEs and offered little
+  practical advice to builders of software engineering tools.
+  This paper presented a theory of programmer navigation when debugging
   based on information foraging theory.
-  (add sentence elaborating on connection to ift)
-  (add sentence about user study)
-  (add sentence about providing first principled design guidelines for making interactive debuggers)
-
+  Information foraging theory is an instance of rational analysis, a
+  methodology for modeling cognitive processes as optimization functions
+  over environmental and (minimally assumed) cognitive constraints---in
+  particular, without reliance on hypothesized mental structures.
+  This paper followed Sjøberg et al.'s theory-building process
+  :cite:`sjoberg2008building`: it adapted the constructs of information
+  foraging theory to programmer navigation during debugging; empirically
+  investigated the circumstances in which the theory is applicable; and
+  empirically evaluated the theory's predictive power.
 
 
 Interactive Debuggers
 ---------------------
 
-describe history of transition from physical computing
-systems to observing core dumps
-to more interactive stepping and navigation, graphical
-projections of execution behavior onto source code, etc
+.. todo::
+  describe history of transition from physical computing
+  systems to observing core dumps
+  to more interactive stepping and navigation, graphical
+  projections of execution behavior onto source code, etc
 
 Interactive Breakpoints
 ^^^^^^^^^^^^^^^^^^^^^^^
@@ -112,57 +135,131 @@ Time-Travel Debugging
 Program Slicing
 ^^^^^^^^^^^^^^^
 
-(add description of program slicing as decomposition of programs)
-(provide some overview of different types of program slicing, e.g., static vs dynamic)
+**Program slicing** is a technique for computing, given some subset of a program's behavior,
+the corresponding subset of the program that produces that behavior.
+A **slicing criterion** specifies the target behavior; the corresponding program subset
+is called a **program slice**.
+For example, in the original formulation :cite:`weiser1981slicing`, Weiser defines a
+slicing criterion as consisting of a program statement and a subset of program
+variables; a program slice is an executable subset of the original program, obtained by
+deleting program statements that do not affect the criterion variables' runtime
+values at the criterion statement.
+
+(another short paragraph about how program slicing has been generalized,
+forward vs backward, static vs dynamic, amorphous, execution slices)
 
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
     :filter: key == 'weiser1981slicing'
 
-  This paper introduced program slicing.
-  (add details about static slices)
+  This paper introduced the concept of program slicing.
+  The specific proposed technique would now be categorized as static, backward slicing.
+  In this work, the slicing criterion is a program statement and a subset of program
+  variables; a program slice is an executable subset of the original program, obtained
+  by deleting program statements that do not affect the criterion variables' runtime
+  values at the criterion statement.
+  The paper showed that the problem of computing minimal static slices is undecidable,
+  but that approximate static slices can be found using data flow analysis.
+
 
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
     :filter: key == 'ko2008whyline'
 
-  (describe connection to earlier work on debugging theory)
-  (describe the tool and how it uses dynamic program slicing)
-  (describe user study and result)
+  This paper presented a new debugging interface for Java programs called Whyline.
+  Unlike prior debugging interfaces---which typically require the user to select
+  particular pieces of code of interest and, thus, require translation of questions
+  into code queries---Whyline allows the user to select a "why did" or "why didn't"
+  question about some program output and then generates an answer using dynamic,
+  backward program slicing.
+  The answer is presented as a visualization of the relevant execution slice,
+  which the user can explore interactively, again by selecting "why did"
+  and "why didn't" questions about runtime values.
+  The paper described aspects of the Whyline's design and implementation---in
+  particular, how the tool derives useful questions about program output.
+  The authors noted that effective question generation was highly domain-dependent
+  ---in this case, the program output was graphical.
+  An evaluation of the Whyline on one task showed that novice programmers
+  with Whyline were twice as fast as expert programmers without it.
 
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
     :filter: key == 'perera2012explain'
 
-  (static and dynamic program slicing for functional programs)
-  (no implementation or evaluation)
+  This paper developed novel foundations and conceptual user interactions
+  for dynamic, backward program slicing of higher-order functional programs.
+  Prior slicing methods, primarily developed for imperative programs, were
+  restricted to slicing at the granularity of variables---a poor fit for
+  the complex values (e.g., higher-order functions, recursive data types)
+  prevalent in the functional setting.
+  In this work, given a program execution, a slicing criterion is a partial
+  manifestation of the output value, in which only subvalues of interest
+  are present and all others are replaced with holes;
+  a program slice is a partial program expression, where
+  subexpressions irrelevant to the criterion are replaced by holes.
+  The paper also developed a corresponding notion of an execution slice---
+  a tree-structured "unrolling" of the reduction steps leading to
+  the specified partial value, where criterion-irrelevant nodes are
+  are also replaced by holes.
+  The paper presented algorithms for computing least program and trace
+  slices, proved the algorithms correct, and presented a prototype
+  implementation of these techniques as a tool called Slicer.
+  Given a program execution and a slicing criterion, Slicer generates
+  a visualization of the least program and execution slice.
+  While these visualizations are static, the authors use them to sketch
+  the concept of a novel interactive debugging interface, leaving
+  the implementation and evaluation of such an interface to future work.
+
+  .. note::
+    The authors presented execution slicing as a novel concept, but variants
+    had already appeared in prior work, e.g., slicing ARTs in
+    :cite:`silva2006adps`, the execution slice visualization in WhyLine
+    :cite:`ko2008whyline`.
 
 Reachability Questions
 ^^^^^^^^^^^^^^^^^^^^^^
 
+A *reachability question* is a search across feasible paths through a
+program for target statements matching search criteria.
+Common reachability questions are expressed as queries about statements
+that can execute downstream/upstream from a particular origin/destination
+program statement.
+Program slicing may be viewed as an instance of a reachability question,
+where the query is to return all control and data dependencies of some
+statement.
+
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
     :filter: key == 'latoza2010reachability'
 
-  This paper introduced the concept and formalism of
-  *reachability questions*: searches across feasible paths through a
-  program for target statements matching search criteria.
-  (add another sentence about user studies and prevalence of reachability questions)
+  This paper introduced the concept and formalism of reachability questions.
+  It reported the results of three separate studies---a lab study of 13 developers,
+  a survey of 460 developers, and a field study of 17 developers---and found that
+  reachability questions are quite prevalent and often time consuming to answer.
+  In the survey, developers reported asking questions that could be expressed as
+  reachability questions more than 9 times a day. In the field study, the authors
+  found that 9 of the 10 longest activities were associated with reachability
+  questions.
 
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
     :filter: key == 'latoza2011reacher'
 
-  (describe connection to earlier work on reachability questions)
-  (describe the tool)
-  (describe user study and results)
-  (should probably move this out of program slicing)
-
+  Motivated by the results of :cite:`latoza2010reachability`, this paper presented
+  a novel debugging tool called Reacher that directly supports asking and answering
+  reachability questions. Upon user selection of an origin/destination statement,
+  Reacher supports searching downstream/upstream along feasible control
+  flow paths for statements matching user-specified criteria. Search results
+  selected by the user are aggregated and visually displayed as a call graph.
+  Users can interact with the call graph to navigate to corresponding source
+  code and to iteratively refine the graph to display more details as needed.
+  In a lab study with 12 participants, users with Reacher were over 5 times more successful
+  completing their tasks in significantly less time than with an existing IDE.
 
 
 Algorithmic Debugging
@@ -197,17 +294,33 @@ widespread use. (add note about functional programming research lagging in tooli
   .. bibliography:: debugging.bib
     :filter: key == 'nilsson1994lazy'
 
-  This paper introduced the use of algorithmic debugging---originally developed
-  for logic programs---for debugging lazy functional programs. (add sentence about
-  how algorithmic debugging is useful when evaluation order doesn't matter)
+  .. todo::
+    write bib entry
 
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
     :filter: key == 'silva2006adps'
 
-  This paper noted the complementary strengths of program slicing and algorithmic
-  debugging and unified them in a common theoretical framework.
+  This paper combined program slicing and algorithmic debugging
+  into a unified debugging framework for functional programs, adapting
+  similar combinations applied to logic and imperative programs.
+  The paper was motivated by the authors' observation that AD tools would produce
+  long series of semantically loosely connected and, from the user's perspective,
+  redundant questions.
+  Program slicing provides a complementary remedy: rather than just 'correct'
+  or 'incorrect',
+  the user may provide a slicing criterion specifying which parts of the
+  subcomputation's result are incorrect; the slicing criterion is used to prune
+  the debugging tree of irrelevant subcomputations, leading to more semantically
+  connected questions.
+  The paper adapted program slicing concepts to the Augmented Redex Trail (ART), a
+  trace structure that can be the basis for both AD and program slicing, and presented
+  an algorithm for slicing ARTs.
+
+  .. note::
+    The debugging interface sketched in :cite:`perera2012explain` may be viewed
+    as combining program slicing and algorithmic debugging.
 
 .. container:: bib-item
 

From 8d75797f17029f20856a94955cddfe657aa1acfd Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Mon, 16 Dec 2019 14:33:51 -0500
Subject: [PATCH 05/12] Remove note about fp tool research

---
 src/live-programming.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/live-programming.rst b/src/live-programming.rst
index 4d9bf3e..fd9a063 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -287,7 +287,7 @@ must maintain an understanding of how any *subsequent ET node* depends on those
 values.
 
 Despite their useful guarantee of bug diagnosis, algorithmic debuggers have yet to enter
-widespread use. (add note about functional programming research lagging in tooling)
+widespread use.
 
 .. container:: bib-item
 

From 10df4eb36a757b01e6a50a7f73f1c99606dd9804 Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Mon, 16 Dec 2019 20:48:51 -0500
Subject: [PATCH 06/12] Add bib entries for og ad + lazy ad

---
 src/debugging.bib        | 10 ++++++++++
 src/live-programming.rst | 23 +++++++++++++++++++++--
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/src/debugging.bib b/src/debugging.bib
index e35cf46..a626937 100644
--- a/src/debugging.bib
+++ b/src/debugging.bib
@@ -201,3 +201,13 @@ @inbook{sjoberg2008building
 journal = {Guide to Advanced Empirical Software Engineering},
 doi = {10.1007/978-1-84800-044-5_12}
 }
+
+@phdthesis{shapiro1982ad,
+ author = {Shapiro, Ehud Yehuda},
+ title = {Algorithmic Program Debugging},
+ year = {1982},
+ note = {AAI8221751},
+ school={Yale University},
+ publisher = {Yale University},
+ address = {New Haven, CT, USA},
+}
diff --git a/src/live-programming.rst b/src/live-programming.rst
index fd9a063..c6113cc 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -289,13 +289,32 @@ values.
 Despite their useful guarantee of bug diagnosis, algorithmic debuggers have yet to enter
 widespread use.
 
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'shapiro1982ad'
+
+  Ehud Shapiro first developed algorithmic debugging for Prolog, a logic programming
+  language, during his PhD research. His PhD thesis on the topic was
+  selected as a 1982 ACM Distinguished Dissertation.
+
 .. container:: bib-item
 
   .. bibliography:: debugging.bib
     :filter: key == 'nilsson1994lazy'
 
-  .. todo::
-    write bib entry
+  This paper proposed algorithmic debugging techniques for lazy functional programs.
+  Traditional debugging techniques are ill-suited for lazily evaluated programs
+  because computations generally do not take place in the order one might expect
+  from reading the source code, thus leading to difficulty orienting oneself in the
+  the process of following program execution. Algorithmic debugging, on the other
+  hand, allows the user to concentrate on the declarative semantics of a program,
+  rather than its operational aspects such as evaluation order. While basic algorithmic
+  debugging :cite:`shapiro1982ad` may readily be used for lazy functional languages,
+  the prevalance of partially evaluated expressions during lazy evaluation makes
+  the questions generated by the debugger difficult to comprehend and answer.
+  This paper first identified this problem and proposed a solution that provides
+  the user with a *strictified* view of the execution tree.
 
 .. container:: bib-item
 

From fedb4a305ea96356cae9bf123f2844e5e1d5fc32 Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Mon, 16 Dec 2019 22:15:46 -0500
Subject: [PATCH 07/12] Add bib entry for Xu survey + trim bib info

---
 src/debugging.bib        | 103 +++++----------------------------------
 src/live-programming.rst |  12 +++++
 2 files changed, 25 insertions(+), 90 deletions(-)

diff --git a/src/debugging.bib b/src/debugging.bib
index a626937..0b64633 100644
--- a/src/debugging.bib
+++ b/src/debugging.bib
@@ -2,39 +2,20 @@ @article{lawrance2013foraging
  author = {Lawrance, Joseph and Bogart, Christopher and Burnett, Margaret and Bellamy, Rachel and Rector, Kyle and Fleming, Scott D.},
  title = {How Programmers Debug, Revisited: An Information Foraging Theory Perspective},
  journal = {IEEE Trans. Softw. Eng.},
- issue_date = {February 2013},
  volume = {39},
  number = {2},
- month = feb,
  year = {2013},
- issn = {0098-5589},
  pages = {197--215},
- numpages = {19},
- url = {https://doi.org/10.1109/TSE.2010.111},
- doi = {10.1109/TSE.2010.111},
- acmid = {2478703},
- publisher = {IEEE Press},
- address = {Piscataway, NJ, USA},
- keywords = {Approximation methods, Debugging, Information foraging theory, Navigation, Predictive models, Programming environments, Topology, debugging, empirical software engineering, information scent, programmer navigation, software maintenance},
 }
 
 @article{ko2005framework,
  author = {Ko, Andrew J. and Myers, Brad A.},
  title = {A Framework and Methodology for Studying the Causes of Software Errors in Programming Systems},
  journal = {J. Vis. Lang. Comput.},
- issue_date = {February, 2005},
  volume = {16},
  number = {1-2},
- month = feb,
  year = {2005},
- issn = {1045-926X},
  pages = {41--84},
- numpages = {44},
- url = {http://dx.doi.org/10.1016/j.jvlc.2004.08.003},
- doi = {10.1016/j.jvlc.2004.08.003},
- acmid = {1747434},
- publisher = {Academic Press, Inc.},
- address = {Orlando, FL, USA},
 }
 
 @inproceedings{latoza2010reachability,
@@ -43,36 +24,25 @@ @inproceedings{latoza2010reachability
  booktitle = {Proceedings of the 32Nd ACM/IEEE International Conference on Software Engineering - Volume 1},
  series = {ICSE '10},
  year = {2010},
- isbn = {978-1-60558-719-6},
  location = {Cape Town, South Africa},
  pages = {185--194},
- numpages = {10},
- url = {http://doi.acm.org/10.1145/1806799.1806829},
- doi = {10.1145/1806799.1806829},
- acmid = {1806829},
- publisher = {ACM},
- address = {New York, NY, USA},
- keywords = {code navigation, developer questions, empirical study, program comprehension, software maintenance},
 }
 
 @article{caballero2017survey,
 author = {Caballero, Rafael and Riesco, Adrián and Silva, Josep},
 year = {2017},
-month = {08},
 pages = {1-35},
 title = {A Survey of Algorithmic Debugging},
 volume = {50},
 journal = {ACM Computing Surveys},
-doi = {10.1145/3106740}
 }
 
 @article{nilsson1994lazy,
 author={Nilsson, Henrik and Fritzson, Peter},
 title={Algorithmic debugging for lazy functional languages},
-volume={4}, DOI={10.1017/S095679680000109X},
+volume={4},
 number={3},
 journal={Journal of Functional Programming},
-publisher={Cambridge University Press},
 year={1994},
 pages={337–369}
 }
@@ -83,16 +53,7 @@ @inproceedings{perera2012explain
  booktitle = {Proceedings of the 17th ACM SIGPLAN International Conference on Functional Programming},
  series = {ICFP '12},
  year = {2012},
- isbn = {978-1-4503-1054-3},
- location = {Copenhagen, Denmark},
  pages = {365--376},
- numpages = {12},
- url = {http://doi.acm.org/10.1145/2364527.2364579},
- doi = {10.1145/2364527.2364579},
- acmid = {2364579},
- publisher = {ACM},
- address = {New York, NY, USA},
- keywords = {debugging, program slicing, provenance},
 }
 
 @inproceedings{weiser1981slicing,
@@ -101,15 +62,7 @@ @inproceedings{weiser1981slicing
  booktitle = {Proceedings of the 5th International Conference on Software Engineering},
  series = {ICSE '81},
  year = {1981},
- isbn = {0-89791-146-6},
- location = {San Diego, California, USA},
  pages = {439--449},
- numpages = {11},
- url = {http://dl.acm.org/citation.cfm?id=800078.802557},
- acmid = {802557},
- publisher = {IEEE Press},
- address = {Piscataway, NJ, USA},
- keywords = {Data flow analysis, Debugging, Human factors, Program maintenance, Program metrics, Software tools},
 }
 
 @inproceedings{ko2004whyline,
@@ -118,16 +71,7 @@ @inproceedings{ko2004whyline
  booktitle = {Proceedings of the SIGCHI Conference on Human Factors in Computing Systems},
  series = {CHI '04},
  year = {2004},
- isbn = {1-58113-702-8},
- location = {Vienna, Austria},
  pages = {151--158},
- numpages = {8},
- url = {http://doi.acm.org/10.1145/985692.985712},
- doi = {10.1145/985692.985712},
- acmid = {985712},
- publisher = {ACM},
- address = {New York, NY, USA},
- keywords = {Alice, debugging, program slicing},
 }
 
 @inproceedings{ko2008whyline,
@@ -136,16 +80,7 @@ @inproceedings{ko2008whyline
  booktitle = {Proceedings of the 30th International Conference on Software Engineering},
  series = {ICSE '08},
  year = {2008},
- isbn = {978-1-60558-079-1},
- location = {Leipzig, Germany},
  pages = {301--310},
- numpages = {10},
- url = {http://doi.acm.org/10.1145/1368088.1368130},
- doi = {10.1145/1368088.1368130},
- acmid = {1368130},
- publisher = {ACM},
- address = {New York, NY, USA},
- keywords = {whyline},
 }
 
 @inproceedings{silva2006adps,
@@ -154,16 +89,7 @@ @inproceedings{silva2006adps
  booktitle = {Proceedings of the 8th ACM SIGPLAN International Conference on Principles and Practice of Declarative Programming},
  series = {PPDP '06},
  year = {2006},
- isbn = {1-59593-388-3},
- location = {Venice, Italy},
  pages = {157--166},
- numpages = {10},
- url = {http://doi.acm.org/10.1145/1140335.1140355},
- doi = {10.1145/1140335.1140355},
- acmid = {1140355},
- publisher = {ACM},
- address = {New York, NY, USA},
- keywords = {algorithmic debugging, program slicing},
 }
 
 @INPROCEEDINGS{latoza2011reacher,
@@ -171,13 +97,8 @@ @INPROCEEDINGS{latoza2011reacher
 booktitle={2011 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC)},
 title={Visualizing call graphs},
 year={2011},
-volume={},
-number={},
 pages={117-124},
-keywords={program debugging;program visualisation;reverse engineering;interactive call graph visualization;REACHER;program visualization;program comprehension;control flow;Visualization;Navigation;Context;Joining processes;Debugging;Vegetation;Upper bound;code exploration;call graphs;control flow;program visualization;program comprehension},
-doi={10.1109/VLHCC.2011.6070388},
-ISSN={},
-month={Sep.},}
+}
 
 @ARTICLE{araki1991framework,
 author={K. {Araki} and Z. {Furukawa} and J. {Cheng}},
@@ -187,27 +108,29 @@ @ARTICLE{araki1991framework
 volume={8},
 number={3},
 pages={14-20},
-keywords={program debugging;programming;supervisory programs;debugged process model;general debugging framework;traditional debugging processes;support tools;debugging methodologies;execution monitor;Eden;Programming profession;Error correction;Logic;Probes;Software debugging;Software tools;Computer industry;Computer bugs;History;Graphics},
-doi={10.1109/52.88939},
-ISSN={},
-month={May},}
+}
 
 @inbook{sjoberg2008building,
 author = {Sjøberg, Dag and Dybå, Tore and Anda, Bente and Hannay, Jo},
 year = {2008},
-month = {01},
 pages = {312-336},
 title = {Building Theories in Software Engineering},
 journal = {Guide to Advanced Empirical Software Engineering},
-doi = {10.1007/978-1-84800-044-5_12}
 }
 
 @phdthesis{shapiro1982ad,
  author = {Shapiro, Ehud Yehuda},
  title = {Algorithmic Program Debugging},
  year = {1982},
- note = {AAI8221751},
  school={Yale University},
- publisher = {Yale University},
- address = {New Haven, CT, USA},
 }
+
+@article{xu2005survey,
+ author = {Xu, Baowen and Qian, Ju and Zhang, Xiaofang and Wu, Zhongqiang and Chen, Lin},
+ title = {A Brief Survey of Program Slicing},
+ journal = {SIGSOFT Softw. Eng. Notes},
+ volume = {30},
+ number = {2},
+ year = {2005},
+ pages = {1--36},
+}
\ No newline at end of file
diff --git a/src/live-programming.rst b/src/live-programming.rst
index c6113cc..aa22717 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -145,6 +145,9 @@ variables; a program slice is an executable subset of the original program, obta
 deleting program statements that do not affect the criterion variables' runtime
 values at the criterion statement.
 
+Since Weiser's introduction of program slicing, researchers have proposed various
+extensions and generalizations. These include
+
 (another short paragraph about how program slicing has been generalized,
 forward vs backward, static vs dynamic, amorphous, execution slices)
 
@@ -162,6 +165,15 @@ forward vs backward, static vs dynamic, amorphous, execution slices)
   The paper showed that the problem of computing minimal static slices is undecidable,
   but that approximate static slices can be found using data flow analysis.
 
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'xu2005survey'
+
+  This paper surveyed a wide variety of extensions and variations of program slicing
+  that had been developed since Weiser first proposed the technique in 1981
+  :cite:`weiser1981slicing`.
+
 
 .. container:: bib-item
 

From bec89e5cb8e4f3224adf5cb31d16f21cff4202e6 Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Mon, 16 Dec 2019 22:42:58 -0500
Subject: [PATCH 08/12] Add final paragraph for program slicing intro

---
 src/live-programming.rst | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/src/live-programming.rst b/src/live-programming.rst
index aa22717..869d817 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -139,17 +139,21 @@ Program Slicing
 the corresponding subset of the program that produces that behavior.
 A **slicing criterion** specifies the target behavior; the corresponding program subset
 is called a **program slice**.
-For example, in the original formulation :cite:`weiser1981slicing`, Weiser defines a
+For example, in the original formulation :cite:`weiser1981slicing`, Weiser defined a
 slicing criterion as consisting of a program statement and a subset of program
 variables; a program slice is an executable subset of the original program, obtained by
 deleting program statements that do not affect the criterion variables' runtime
 values at the criterion statement.
 
-Since Weiser's introduction of program slicing, researchers have proposed various
-extensions and generalizations. These include
-
-(another short paragraph about how program slicing has been generalized,
-forward vs backward, static vs dynamic, amorphous, execution slices)
+Since Weiser's introduction of program slicing, researchers have proposed many
+variations and extensions. For example, whereas Weiser's notion of a program
+slice is a **backwards** slice consisting of statements that may affect the
+slicing criterion, a **forwards** slice consists of statements that may be
+influenced by the slicing criterion.
+Weiser focused on **static** slicing, which takes into account all possible
+executions of the program, while other tools incorporate **dynamic** slicing,
+which computes program slices with respect to a specific execution.
+Additional variations are reviewed in :cite:`xu2005survey`.
 
 .. container:: bib-item
 

From 0b9309c8ad4ef864fae3cbf1af6681742a2e025f Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Mon, 16 Dec 2019 22:50:59 -0500
Subject: [PATCH 09/12] Remove mention of theory building or rational analysis
 from info foraging paper

---
 src/live-programming.rst | 13 +++----------
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/src/live-programming.rst b/src/live-programming.rst
index 869d817..d0b918f 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -99,16 +99,9 @@ debugging interfaces influence those processes.
   navigational activities performed in modern IDEs and offered little
   practical advice to builders of software engineering tools.
   This paper presented a theory of programmer navigation when debugging
-  based on information foraging theory.
-  Information foraging theory is an instance of rational analysis, a
-  methodology for modeling cognitive processes as optimization functions
-  over environmental and (minimally assumed) cognitive constraints---in
-  particular, without reliance on hypothesized mental structures.
-  This paper followed Sjøberg et al.'s theory-building process
-  :cite:`sjoberg2008building`: it adapted the constructs of information
-  foraging theory to programmer navigation during debugging; empirically
-  investigated the circumstances in which the theory is applicable; and
-  empirically evaluated the theory's predictive power.
+  based on information foraging theory, which relies only on
+  environmental and (minimally assumed) cognitive constraints
+  to model cognitive processes.
 
 
 Interactive Debuggers

From 982b649babccf9e3cbdce300eced1d5a7fd26e00 Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Mon, 16 Dec 2019 23:44:00 -0500
Subject: [PATCH 10/12] Finish first paragraph

---
 src/live-programming.rst | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/src/live-programming.rst b/src/live-programming.rst
index d0b918f..8b116eb 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -31,11 +31,9 @@ Debugging
 Much of the activity of programming involves **debugging**, i.e.,
 diagnosing and preventing undesired program behavior.
 Wilkes's early realization of this fact was echoed and amplified in a 2002
-study of the U.S. software industry, which found that software engineers
-spent an average of 70-80% of their time testing and debugging, with
-the average bug taking 17.4 hours to fix.
+study of the U.S. software industry, which found that the average
+bug took 17.4 hours to investigate and fix.
 Thus, debuggers form a crucial component of an effective programming system.
-(needs better finish)
 
 Software bugs manifest at three levels. Typically a bug is first
 observed as a **runtime failure**, an instance of external program

From 826bfad8eb2e4974223c5360a565aff6cc0af46d Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Mon, 16 Dec 2019 23:49:32 -0500
Subject: [PATCH 11/12] Add nist survey bib

---
 src/debugging.bib        | 7 +++++++
 src/live-programming.rst | 7 ++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/debugging.bib b/src/debugging.bib
index 0b64633..d9614fe 100644
--- a/src/debugging.bib
+++ b/src/debugging.bib
@@ -133,4 +133,11 @@ @article{xu2005survey
  number = {2},
  year = {2005},
  pages = {1--36},
+}
+
+@article{tassey2002nist,
+author = {Tassey, Gregory},
+year = {2002},
+journal={},
+title = {The Economic Impacts of Inadequate Infrastructure for Software Testing}
 }
\ No newline at end of file
diff --git a/src/live-programming.rst b/src/live-programming.rst
index 8b116eb..3a1cb45 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -31,7 +31,7 @@ Debugging
 Much of the activity of programming involves **debugging**, i.e.,
 diagnosing and preventing undesired program behavior.
 Wilkes's early realization of this fact was echoed and amplified in a 2002
-study of the U.S. software industry, which found that the average
+study :cite:`tassey2002nist` of the U.S. software industry, which found that the average
 bug took 17.4 hours to investigate and fix.
 Thus, debuggers form a crucial component of an effective programming system.
 
@@ -52,6 +52,11 @@ occurring. A **debugger** is a tool that allows the programmer to observe
 the machine state during program execution, thereby making it possible to
 identify runtime faults.
 
+.. container:: bib-item
+
+  .. bibliography:: debugging.bib
+    :filter: key == 'tassey2002nist'
+
 Theories of Human Debugging
 ---------------------------
 

From dbe77ed438809db888925ffa9b85d25104686a66 Mon Sep 17 00:00:00 2001
From: David Moon <dmoon1221@gmail.com>
Date: Mon, 16 Dec 2019 23:51:23 -0500
Subject: [PATCH 12/12] nits

---
 src/live-programming.rst | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/live-programming.rst b/src/live-programming.rst
index 3a1cb45..754cbfd 100644
--- a/src/live-programming.rst
+++ b/src/live-programming.rst
@@ -47,8 +47,8 @@ the source code.
 Using these terms, debugging may be understood
 more precisely as the collective processes of determining what runtime
 faults led to a runtime failure, determining what software errors
-led to those faults, and modifying the code to prevent the faults from
-occurring. A **debugger** is a tool that allows the programmer to observe
+led to those faults, and eliminating the errors.
+A **debugger** is a tool that allows the programmer to observe
 the machine state during program execution, thereby making it possible to
 identify runtime faults.
 
@@ -278,8 +278,8 @@ Algorithmic Debugging
 ^^^^^^^^^^^^^^^^^^^^^
 
 *Algorithmic debugging* (also called *declarative debugging*) is a semi-automatic
-debugging technique in which the debugger automatically generates a series of
-questions to which the programmer's answers guide the search toward the bug.
+debugging technique in which the debugger guides the programmer toward the
+bug by asking a series of questions.
 The debugger constructs an *execution tree* (ET), a data structure representing a
 program execution, and traverses it using some search strategy, asking the
 programmer at each ET node whether the represented subcomputation is correct
@@ -290,8 +290,8 @@ the bug will eventually be found.
 Although algorithmic debugging can be applied in any language paradigm, it is most
 suited for declarative languages, e.g., pure functional languages.
 To determine whether an ET node for a pure functional program is correct, the
-programmer need only check that the return value of the corresponding, referentially
-transparent expression is the expected one, independent of any other ET node.
+programmer need only check that the return value of the corresponding
+expression is the expected one, independent of any other ET node.
 On the other hand, checking the correctness of an ET node for an imperative program
 requires checking, in addition to the return value, that values in the heap have
 been updated correctly---this can be difficult to ascertain because the programmer