discussion.tex
3.04 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
\section{Discussion}
\label{sec-discussion}
We have yet to determine how well programmers will be able to use the
\texttt{maybe} statement. Structurally \texttt{maybe} statements are similar
to the ubiquitous \texttt{if-else} construct in that at the bottom of the
statement the programmer may not be sure which block was executed. However,
while with \texttt{if-else} blocks it can be determined which block was
executed by examining the branch conditions, \texttt{maybe} statements
require developers to record which alternative was executed if downstream
code depends on the decision. To coordinate the adaptation of multiple code
paths a single \texttt{maybe} variable---such as the policy string in
Figure~\ref{fig-maybeexamples}---can be used to control multiple
\texttt{if-else} statements.
While \texttt{maybe} is a powerful programming tool, it is important that it
be used sparingly. If objective dependencies exist between \texttt{maybe}
statements, the overall configuration space may expand exponentially,
complicating the process of determining the best alternatives described in
Section~\ref{sec-certainty}. (A similar problem exists with nested
\texttt{maybe} statements.) Compile-time analysis may be required to detect
dependencies between \texttt{maybe} statements and ensure that downstream
optimization remains feasible.
One important place where \texttt{maybe} should not be used is when
adaptation is not app-specific and can be refactored into a library serving
multiple apps. 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 choice would be better refactored into a
dedicated library, which might use its own internal \texttt{maybe}
statements. Not only is the resulting codebase smaller, but the total number
of \texttt{maybe} statements that the system has to determine how to handle
is reduced.
However, the \texttt{maybe} statement represents a fundamentally different
approach from previously attempts to enable runtime adaptation that relied on
libraries. As a code organization stategy, the benefits that libraries provide
in terms of reduced duplication and more powerful interfaces are orthogonal and
complementary to the \texttt{maybe} statement. That said, a large amount of
code including adaptation logic remains app specific and cannot be refactored
into a library.
More importantly, library development still requires development-time
certainty. Despite the fact that library developers are more likely to be
experts at the type of adaptation the library performs, we still believe that
even the most skilled programmers are not capable of anticipating all
possible sources of uncertainty and 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 needed
required to enable powerful data-driven approaches to post-deployment
adaptation.