|
|
1
2
3
|
\section{Discussion}
\label{sec-discussion}
|
|
|
4
5
|
We have yet to determine how natural programmers will find the \texttt{maybe}
statement. Encouragingly, \texttt{maybe} statements are similar to the
|
|
|
6
7
8
9
|
ubiquitous \texttt{if-else} statement, and in many cases can directly replace
\texttt{if-else} statements that attempt runtime adaptation. To coordinate
the adaptation of multiple code paths a single \texttt{maybe} variable can be
used to control multiple \texttt{if-else} statements.
|
|
|
10
|
|
|
|
11
12
13
14
15
16
|
Overuse of the \texttt{maybe} statement may cause problems. If dependencies
exist between \texttt{maybe} statements, the overall configuration space may
expand exponentially, complicating post-deployment adaptation. Compile-time
analysis may be required to detect dependencies between \texttt{maybe}
statements and encourage programmers to limit their use of \texttt{maybe} to
ensure that downstream optimization remains feasible.
|
|
|
17
|
|
|
|
18
19
20
21
22
23
24
|
\texttt{maybe} statements should not be used when adaptation can be
refactored into a library. As an example, an app should not use
\texttt{maybe} to decide which network interface to use when attempting to
achieve a common objective, such as maximizing throughput. This adaptation
should be refactored into a dedicated library, which might use its own
\texttt{maybe} statements. Not only is the resulting codebase smaller, but
the total number of \texttt{maybe} statements to test is reduced.
|
|
|
25
26
|
However, the \texttt{maybe} statement represents a fundamentally different
|
|
|
27
28
29
30
31
32
33
34
35
|
approach to runtime adaptation than systems that rely on libraries because
library development still requires development-time certainty. While library
developers are more likely to be experts at the type of adaptation their
library performs, we still believe that even the most skilled programmers
will benefit from being able to express structured uncertainty.
\texttt{maybe} allows all developers---including both app and library
writers---to shed the burden of producing a single certain approach and
instead write uncertain code containing the flexibility required to enable
powerful data-driven approaches to post-deployment adaptation.
|
