Final pass.

Geoffrey Challen
1 parent b6686674
Showing 3 changed files with 61 additions and 60 deletions
introduction.tex
maybe.tex
paper.tex
@@ -19,7 +19,7 @@ Today programmers are forced to anticipate these changing conditions at
 development time and implement the required adaptation themselves.
 Figure~\ref{fig-example-if} shows an example of an Android app attempting to
 adapt to the device's battery level by establishing regular- and low-battery
-code paths, with the latter attempting to save energy, possibly by utilizing
+code paths, with the latter attempting to save energy---possibly by utilizing
 a slower but more energy-efficient algorithm, computing an approximate
 result, or deferring the computation.
  
@@ -28,22 +28,22 @@ important is perhaps the least obvious: it is unclear that the different code
 paths achieve the desired result. There may be no differences between the
 alternatives (neither conserves energy), the alternative designed to conserve
 energy may actually consume more due to bugs or incorrect assumptions, or the
-result may also depend on some other factor not considered by the programmer,
-such as the type of network the device is currently using.
+outcome may depend on other factors not considered by the programmer, such as
+the type of network the device is currently using.
  
-In addition, adaptive programming frequently requires arbitrary decision
-thresholds chosen before deployment. Even if the two code paths shown in
+In addition, attempts at pre-deployment adaptation frequently produce
+arbitrary decision thresholds. Even if the two code paths in
 Figure~\ref{fig-example-if} achieve the desired result, it is unclear what
-the threshold for choosing a path should be, whether a single threshold
-will work for all users, and whether the threshold should depend on
-other factors such as how frequently the app is used.
+battery level threshold should trigger the energy-saving path, whether a
+single threshold will work for all users, and whether the threshold should
+depend on other factors such as how frequently the app is used.
  
 \begin{figure}[t]
 \begin{minted}[fontsize=\footnotesize]{java}
 if (plugged == false && batteryLevel < 10) {
- // Attempt to save energy
+ // Try to save energy
 } else {
- // Don't attempt to save energy
+ // Don't try to save energy
 }
 \end{minted}
  
@@ -61,64 +61,66 @@ only for certain users, only on certain devices, or never.}
  
 Finally, the current approach to adaptation fails to support post-deployment
 testing. While it is possible to enable flexibility, runtime adaptation, and
-split testing using the languages typically used to program mobile systems,
-these common tasks require writing large amounts of error-prone boilerplate
-code, including APIs to adjust values at runtime and code to retrieve
-settings from remote servers.
-
-The root of the problem is that \textbf{today's languages force programmers to
-be certain at a moment when they cannot be}: at development time. While this
-problem is endemic to existing programming languages, when developing mobile
-apps it is magnified by the amount of variation developers must confront. Our
-solution is simple: (1) provide developers with a way to express
-\textit{structured uncertainty}, and (2) use the resulting flexibility to
-enable a large array of downstream tools for resolving uncertainty by
-choosing from the alternatives provided by the developer.
+split testing using the languages currently used to program mobile systems,
+these tasks require writing large amounts of error-prone boilerplate code
+that retrieves settings from remote servers and adjusts values at runtime.
+
+The root of the problem is that \textbf{today's languages force programmers
+to be certain at a moment when they cannot be: at development time.} While
+this problem is endemic to existing programming languages, when developing
+mobile apps it is magnified by the amount of variation developers must
+confront. Our solution is simple: (1) provide developers with a way to
+express \textit{structured uncertainty}, and (2) use the resulting
+flexibility to enable a large array of downstream tools for resolving
+uncertainty by choosing from the alternatives provided by the developer.
  
 \begin{figure}[t]
  
 \begin{minted}[fontsize=\footnotesize]{java}
 maybe {
- // Attempt to save energy
+ // Try to save energy (Alternative 1)
 } or {
- // Don't attempt to save energy
+ // Don't to save energy (Alternative 2)
 }
 \end{minted}
  
-\vspace*{-0.1in}
+\vspace*{-0.2in}
  
-\caption{\small\textbf{Example \texttt{maybe} Statement.} The programmer provides
-multiple equivalent alternatives. The system determines how to choose between
-them at runtime.}
+\caption{\small\textbf{Example \texttt{maybe} Statement.} The programmer
+provides multiple alternatives. The system determines how to choose between
+them.}
  
 \label{fig-example-maybe}
  
-\vspace*{-0.1in}
+\vspace*{-0.2in}
  
 \end{figure}
  
-In this paper, we present a novel a language construct for expressing
-structured uncertainty: the \texttt{maybe} statement. Unlike previous
-approaches to adaptation that relied on language support, \texttt{maybe} does
-not encourage programmers to provide more information about their app to
-allow the compiler to improve performance or guarantee correctness. Rather,
-\texttt{maybe} allows the programmer to express and structure uncertainty by
-providing two or more different \textit{alternatives} implementing multiple
-approaches to runtime adaptation, possibly by making the same
-energy-performance or energy-accuracy tradeoffs described previously.
-Conceptually, \texttt{maybe} extends the process of compilation and
-optimization to include post-deployment testing while also enabling flexible
-adaptation that may produce per-user, per-device, or time-varying solutions.
+\sloppypar{In this paper, we present a novel a language construct for
+expressing structured uncertainty: the \texttt{maybe} statement. Unlike
+previous approaches to adaptation that relied on language support,
+\texttt{maybe} does not encourage programmers to provide more information
+about their app to allow the compiler to improve performance or guarantee
+correctness. Rather, \texttt{maybe} allows the programmer to express and
+structure uncertainty by providing two or more different
+\textit{alternatives} implementing multiple approaches to runtime adaptation.
+Together, multiple alternatives can produce the same energy-performance or
+energy-accuracy tradeoffs described previously. Conceptually, \texttt{maybe}
+extends the process of compilation and optimization to include
+post-deployment testing while also enabling flexible adaptation that may
+produce per-user, per-device, or time-varying decisions.}
  
 Figure~\ref{fig-example-maybe} shows how our earlier example can be easily
-rewritten using a \texttt{maybe} statement. Unlike the previous example
-\texttt{maybe}, does not rely on the developer to implement a decision process
-or correctly anticipate the effects of each alternative. Instead, the
+rewritten using a \texttt{maybe} statement. Unlike the previous example,
+\texttt{maybe} does not rely on the developer to implement a decision process
+or correctly predict the effects of each alternative. Instead, the
 \texttt{maybe} system makes runtime choices about which alternative to use by
 measuring the tradeoffs produced by each alternative and (in this case)
-activating an energy-saving alternative when appropriate. All the developer
-has to do is provide alternatives when they are unsure what to do; the
-\texttt{maybe} system does the rest.
+activating an energy-saving alternative when appropriate. When they are
+unsure what to do, all developers have to do is provide alternatives; the
+\texttt{maybe} system does the rest. \texttt{maybe} allows developers to
+respond to uncertainty with flexibility, which is used to enable
+testing-driven adaptation.
  
 The rest of our paper is structured as follows. We begin by providing a more
 complete description of the \texttt{maybe} statement in
@@ -30,13 +30,13 @@ maybe {
  
 \end{minted}
  
-\vspace*{-0.1in}
+\vspace*{-0.2in}
  
 \caption{\small\textbf{More \texttt{maybe} Statements}}
  
 \label{fig-maybeexamples}
  
-\vspace*{-0.15in}
+\vspace*{-0.2in}
  
 \end{figure}
  
@@ -60,14 +60,14 @@ alternatives are specified, the system chooses one to execute; if only one
 alternative is specified, the system chooses whether or not to execute it.
 Single-alternative \texttt{maybe} statements can encapsulate or reorganize
 logic that does not affect correctness, but may (or may not) produce some
-desirable objective.
+desirable outcome.
  
 Figure~\ref{fig-maybeexamples} shows several extensions of the \texttt{maybe}
 statement providing syntactic sugar. \texttt{maybe} function annotations
 allow uncertainty to be expressed at the function level, with the
 alternatives consisting of multiple function definitions with identical
-signatures. Finally, \texttt{maybe} statements that require custom evaluation
-logic can include an \texttt{evaluate} block as shown in the final example.
+signatures. \texttt{maybe} statements that require custom evaluation logic
+can include an \texttt{evaluate} block as shown in the final example.
 \texttt{evaluate} blocks provide app-specific \textit{a posteriori} logic to
 evaluate the selected alternative. The \texttt{evaluate} block must return a
 single JSON object with two components: (1) a positive integer
@@ -80,11 +80,11 @@ While it should be possible to nest \texttt{maybe} statements, it may require
 compiler support to provide guarantees about how \texttt{maybe} decisions are
 maintained across multiple code blocks. As we gain more experience with our
 rewrite-based prototype, described next in Section~\ref{sec-certainty}, we
-will revisit the question of nesting in future compiler-driven \texttt{maybe}
+will revisit the question of nesting in future compiler-based \texttt{maybe}
 systems.
  
-\sloppypar{As a final remark, note that structured uncertainty is not
-randomness. Randomness weights multiple options statically---there is no
-right or wrong choice. In contrast, the \texttt{maybe} statement indicates
-that during any given execution one alternative may be the right
-choice---even if the developer or system cannot yet identify it.}
+As a final remark, note that structured uncertainty is not randomness.
+Randomness weights multiple options statically---there is no right or wrong
+decision. In contrast, the \texttt{maybe} statement indicates that during any
+given execution one alternative may better than the others. The goal of the
+system is to determine which one.
@@ -82,7 +82,6 @@ Jinghao Shi, Guru Prasad Srinivasa, and Lukasz Ziarek}
 \input{conclusion.tex}
  
 {\scriptsize
-\balance
 \renewcommand{\baselinestretch}{0.8}
 \bibliographystyle{acm}
 \bibliography{references}