Scripts, Notebooks & Abstraction

Scripts, Notebooks & Abstraction

We’ve talked a bit about the differences between scripts and spreadsheet applications – this can be abstracted to talking about programming instructions versus using graphical user interface (GUI) environments, where a GUI limits reproducibility while also complicating doing repretative tasks – repetitive tasks take a lot of time and are error prone. Whenever possible, we want to avoid using a GUI when reproducibility is important.

While we’ve mentioned scripts, we’ve almost exclusively been working in RMarkdown documents, not R scripts. And this warrants breaking down a bit. Each has their place within a research context and within the context of research data management. One of the most important pieces of RDM is documentation and a key peice of documentation is the process of decision making in how one works through their data whether that be in the cleaning or analytical stage of the process. This has been referred to as ‘researcher degrees of freedom’. That is, all the decisions a researcher is at liberty to make in this process, whether it be defining an outlier, rounding a variable, grouping variables (choosing a bin size for age ranges for example), deciding you need to collect more data after having looked at the data, etc. See False-Positive Psychology: Undisclosed Flexibility in Data Collection and Analysis Allows Presenting Anything as Significant available at https://doi.org/10.1177/0956797611417632.

An RMarkdown document, sometimes referred to as an electronic notebook, is an excellent platform by which to maintain a record of these decisions; as you articulate your steps in markdown in plain language, this is directly in line with the code that processes your data. When we talked earlier about literate programming – the idea that programming instructions should be both human and machine interprettable and tell a human what you want the computer to do – an RMarkdown document enhances this concept with its rich context. However, at a certain stage, this rich context may be more appropriately decoupled from the scripting process – especially as we move in the direction of confirmatory analyses, where we define in advance how we’ll be handling the data. In these instances, the context is more appropriately contained within some form of study registration. In such a situation, we can use a script, or a document that contains only our instruction set (R code), perhaps with a few comments, but no markdown.

Exploratory research is hypothesis generating, while confirmatory research is hypothesis testing. It is rare that confirmatory research is every conducted fully independent of exploratory research, as confirmatory research often suggests other paths of inquiry. However, it is critical to clearly differentiate between the two and to document the two processes appropriately, generally where exploratory research is documented while doing the exploration and confirmatory research is documented in advance.

Increased System Complexity

It’s important to note that as we move from a script, to an RMarkdown document, to a GUI we increase the complexity of the system(s) that we’re working in. Essentially, there are more moving parts. We’ll talk about this a bit more when we talk about dependencies, but it’s worth noting here the concept of abstraction as it relates to balancing ease of use of a system with replication – we’ll touch on this again when we look at building visualizations in R. The layers of abstraction in a programming language, like R is, in a simplified form:

0s and 1s -> machine code -> low level programming -> high level programming -> interactive programming (ie scientific computing, scripting) -> electronic notebooks -> GUI applications

This abstraction can make it difficult to understand exactly what’s happening especially as a novice user, but an intuitive framework can help you move between systems. When we write code in R this goes through several stages of processing, often first just with a check and balance to make sure the data will work with the function it’s being fed into, it will then actually run in a lower level language (like C or Fortran), which has been converted into machine code, an even more rudimentary instruction set, which is then stored on disk as binary values and processed by your CPU.

---

This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License

Built and rendered courtesy of RMarkdown from RStudio