diff --git a/introduction.tex b/introduction.tex index 2ecdf5b..ce66716 100644 --- a/introduction.tex +++ b/introduction.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 diff --git a/maybe.tex b/maybe.tex index 896d485..cad4e91 100644 --- a/maybe.tex +++ b/maybe.tex @@ -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. diff --git a/paper.tex b/paper.tex index 3cd6e1c..f1c8e42 100644 --- a/paper.tex +++ b/paper.tex @@ -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}