diff options
author | Boud Roukema <boud@cosmo.torun.pl> | 2021-06-15 01:31:46 +0200 |
---|---|---|
committer | Mohammad Akhlaghi <mohammad@akhlaghi.org> | 2021-06-15 00:56:20 +0100 |
commit | ccce0fb9f9229d015e942b00073f39fc16130dc7 (patch) | |
tree | adbd0ba4dd3cc76232e48549c44d328353f6866a /tex | |
parent | d3ee5799299660b42d7b6211b09ad4b707744e77 (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.tex | 2 | ||||
-rw-r--r-- | tex/src/appendix-existing-tools.tex | 4 |
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. |