aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBoud Roukema <boud@cosmo.torun.pl>2020-04-20 02:15:25 +0200
committerMohammad Akhlaghi <mohammad@akhlaghi.org>2020-04-20 06:03:14 +0100
commit30cfbabba5ae55ca06ae4dee4a24075fed27820a (patch)
tree40c22960cd9b315c38a039dfb57abf5180554d83
parente7bf1849afd18f12ba485304e5699376b951b5f3 (diff)
Minor copyedits - 4.1 Maneage orchestration
This commit reduces about 25 words from the 4.1 Maneage orchestration, aka `make`, section.
-rw-r--r--paper.tex26
1 files changed, 13 insertions, 13 deletions
diff --git a/paper.tex b/paper.tex
index 6773dc5..7d65f8b 100644
--- a/paper.tex
+++ b/paper.tex
@@ -367,28 +367,28 @@ Section \ref{sec:collaborating} discusses the sharing of a built environment, an
\subsection{Job orchestration with Make}
\label{sec:usingmake}
-Scripts (in Shell, Python, or any other high-level language) are usually the first solution that come to mind when non-interactive, or batch, processing is needed.
-However, the inherent complexity and non-linearity of progress, as a project evolves, makes it hard to manage scripts.
-For example, if $90\%$ of a research project is done and only the newly-added final $10\%$ must be executed, a script will re-do the whole project every time.
-It is possible to manually ignore completed parts (with conditionals), however this only adds to the complexity and will discourage experimentation on an already-completed part of the project.
+Scripts (e.g. shell, Python, Perl) are an obvious solution for non-interactive (batch) processing.
+However, the inherent complexity and non-linearity of progress as a project evolves makes it hard to manage scripts.
+For example, if $90\%$ of a research project is done and only the final $10\%$ must be executed, a script will re-do the whole project.
+Completed parts can be manually ignored (with conditionals). However, this adds to the complexity and discourages experimentation on already completed parts of the project.
These problems motivated the creation of Make in the early Unix operating system \citep{feldman79}.
Make contiues to be a core component of modern OSs, is actively maintained, and has withstood the test of time.
The Make paradigm starts from the end: the final \emph{target}.
-In Make, the project is broken into atomic \emph{rules} where each rule has a single \emph{target} file which can depend on any number of \emph{prerequisite} files.
+In Make, the project is broken into atomic \emph{rules}, where each rule has a single \emph{target} file which can depend on any number of \emph{prerequisite} files.
To build the target from the prerequisites, each rule also has a \emph{recipe} (an atomic script).
The plain-text files containing Make source code are called Makefiles.
-Note that Make does not replace scripting languages like the shell, Python or R.
+Make does not replace scripting languages like the shell, Python or R.
It is a higher-level structure enabling modular/atomic scripts (in any language) to be put into a workflow.
-Besides formalizing a project's data lineage, Make also greatly encourages experimentation in a project because a recipe is executed only when at least one prerequisite is more recent than its target.
-Therefore, when only $5\%$ of a project's targets are affected by a change, the other $95\%$ remain dormant.
-Furthermore, Make first examines the full lineage before starting the execution of recipes, and
-it can thus execute independent rules in parallel, further improving the speed and encouraging experimentation.
+Besides formalizing a project's data lineage, Make also greatly encourages experimentation in a project, because a recipe is executed only when at least one prerequisite file is more recent than its target.
+For example, when only $5\%$ of a project's targets are affected by a change, the other $95\%$ remain dormant.
+Furthermore, Make first examines the full lineage before starting the execution of recipes, and it can thus execute independent rules in parallel, improving speed and encouraging experimentation.
+
+Make is well known by many outside of software development communities.
+For example, geophysics students have easily adopted it for the RED project management tool \citep{schwab2000}.
+Very good feedback on the simplicity of using Make has been received from early adopters of Maneage, especially graduate students and postdocs.
-Make is well known by many outside of the software developing communities.
-For example, \citet{schwab2000} report how geophysics students have easily adopted it for the RED project management tool.
-Because of its simplicity, we have also had very good feedback on using Make from the early adopters of Maneage, in particular with graduate students and postdocs.