aboutsummaryrefslogtreecommitdiff
path: root/tex
diff options
context:
space:
mode:
authorBoud Roukema <boud@cosmo.torun.pl>2021-06-15 01:31:46 +0200
committerMohammad Akhlaghi <mohammad@akhlaghi.org>2021-06-15 00:56:20 +0100
commitccce0fb9f9229d015e942b00073f39fc16130dc7 (patch)
treeadbd0ba4dd3cc76232e48549c44d328353f6866a /tex
parentd3ee5799299660b42d7b6211b09ad4b707744e77 (diff)
Futher copyediting on the apendices
In the discussion on criteria that Popper lacks, the last mentioned criteria "including the narrative" is written in such a way that can confuse readers into thinking that only a single criteria is lacking. Hyphenating ('including-the-narrative') has been applied to make the sentence less likely to be misunderstood. The ending of the first paragraph in the "Generational gaps" item in Appendix A.G ("... every few years is not practically possible.") sounds like "not almost possible". So it can cause confusions. Endings that are much clearer include: * is impractical. * is not possible in practice. * is not practical. * is not possible practically. [meaning 2. is less likely in this case] I've selected the first option, also replacing "they" by "scientists" to avoid the misinterpretation that "programming languages ... have their own science field to focus on". This commit and the previous one were "amended" by Mohammad (compared to the original commits that Boud had sent).
Diffstat (limited to 'tex')
-rw-r--r--tex/src/appendix-existing-solutions.tex2
-rw-r--r--tex/src/appendix-existing-tools.tex4
2 files changed, 3 insertions, 3 deletions
diff --git a/tex/src/appendix-existing-solutions.tex b/tex/src/appendix-existing-solutions.tex
index 4ca31d6..2113377 100644
--- a/tex/src/appendix-existing-solutions.tex
+++ b/tex/src/appendix-existing-solutions.tex
@@ -488,7 +488,7 @@ To start a project, the \inlinecode{popper} command-line program builds a templa
By default, Popper runs in a Docker image (so root permissions are necessary and reproducible issues with Docker images have been discussed above), but Singularity is also supported.
See Appendix \ref{appendix:independentenvironment} for more on containers, and Appendix \ref{appendix:highlevelinworkflow} for using high-level languages in the workflow.
-Popper does not comply with the completeness, minimal complexity, and including the narrative criteria.
+Popper does not comply with the completeness, minimal complexity, and including-the-narrative criteria.
Moreover, the scaffold that is provided by Popper is an output of the program that is not directly under version control.
Hence, tracking future low-level changes in Popper and how they relate to the high-level projects that depend on it through the scaffold will be very hard.
In Maneage, users start their projects by branching off the core \inlinecode{maneage} git branch.
diff --git a/tex/src/appendix-existing-tools.tex b/tex/src/appendix-existing-tools.tex
index 99a4284..1db9b3f 100644
--- a/tex/src/appendix-existing-tools.tex
+++ b/tex/src/appendix-existing-tools.tex
@@ -651,10 +651,10 @@ Hinsen\citeappendix{hinsen15} also report a similar problem when attempting to i
Of course, this also applies to tools that these systems use, for example Conda (which is also written in Python, see Appendix \ref{appendix:packagemanagement}).
\subsubsection{Generational gap}
-This occurs primarily for domain scientists (for example astronomers, biologists, or social sciences).
+This occurs primarily for scientists in a given domain (for example, astronomers, biologists, or social scientists).
Once they have mastered one version of a language (mostly in the early stages of their career), they tend to ignore newer versions/languages.
The inertia of programming languages is very strong.
-This is natural because they have their own science field to focus on, and re-writing their high-level analysis toolkits (which they have curated over their career and is often only readable/usable by themselves) in newer languages every few years is not practically possible.
+This is natural because scientists have their own science field to focus on, and re-writing their high-level analysis toolkits (which they have curated over their career and is often only readable/usable by themselves) in newer languages every few years is impractical.
When this investment is not possible, either the mentee has to use the mentor's old method (and miss out on all the newly fashionable tools that many are talking about), or the mentor has to avoid implementation details in discussions with the mentee because they do not share a common language.
The authors of this paper have personal experiences in both mentor/mentee relational scenarios.