Add literature references

- Code Staging in GNU Guix
- Unix shell programming: the next 50 years

notebook/literature.courtesCodeStagingGNU2017.org

@@ -0,0 +1,31 @@
+:PROPERTIES:
+:ID:       11ad06b1-c3ad-4675-9fc0-f651bd62a6d7
+:ROAM_REFS: [cite:@courtesCodeStagingGNU2017]
+:END:
+#+title: Code Staging in GNU Guix
+#+date: 2022-06-11 17:36:08 +08:00
+#+date_modified: 2022-06-11 18:10:24 +08:00>
+#+published: 2017-10-23
+#+author: Courtès, L.
+#+source: https://hal.inria.fr/hal-01580582
+#+language: en
+
+
+- describes the code staging process for package definitions in [[id:be917383-84c4-4bf5-9ca0-b04bfb778f4f][Guix package manager]];
+  mainly describing [[roam:Guix G-expressions]]
+- creating package definitions often certain parts of the definitions to carry through the build stage;
+  oftentimes, these parts of code include additional build instructions for non-trivial packages and additional inputs for that package
+- while S-expressions (sexp) are nice, they can be verbose at times;
+  this is where G-expressions (gexp) comes in handy
+  - gexp are hygenic — they preserve lexical scope across different stages
+  - they can easily refer to the high-level objects (e.g., packages, local file) in the store (i.e., ~/gnu/store~)
+  - first-class Scheme values
+  - binds deployment to staging — when brought into staging, all inputs are also deployed as well
+- use cases for gexps
+  - code sharing between multiple stages;
+    this is mostly present such as defining packages and building them
+  - cross-compilation — there are additional operators to denote "nativeness" where it will refer to the "native" version rather than the target version
+  - package definitions — less verbose definitions which is always nice especially with the use of referring to the absolute file names from the store
+  - system services — the process and lifecycle of system services is similar to defining packages being composed of multiple stages: one in definition and one in building the services in the init system
+  - system tests — they can be defined through the =operating-system= interface which are derivations describing entire operating systems;
+    in Guix, this is implemented through a tool called =marionette= which introduces another stage in the pipeline

notebook/literature.greenbergUnixShellProgramming2021.org

@@ -0,0 +1,37 @@
+:PROPERTIES:
+:ID:       acab6667-11f5-4c85-93ee-627c1db6d574
+:ROAM_REFS: [cite:@greenbergUnixShellProgramming2021]
+:END:
+#+title: Unix shell programming: the next 50 years
+#+date: 2021-08-03 22:42:04 +08:00
+#+date_modified: 2022-06-11 18:23:17 +08:00
+#+published: 2021-06
+#+author: Greenberg, M., Kallas, K., & Vasilakis, N.
+#+source: https://dl.acm.org/doi/10.1145/3458336.3465294
+#+language: en
+
+
+- Unix shell is a long-standing tool with its cruft and history built over the past decades;
+- the goodies
+  - ease of composition gluing tools together easily
+  - mostly found on Unix systems
+  - capabilities for data streaming
+  - interactivity and automation
+- the blockers
+  - too dynamic with its environment that
+  - ease of composition of tools made of different programming languages with different properties made it difficult for research
+  - there's no single shell environment;
+    the current ecosystem is made of multiple implementation of the POSIX shell which is made of ~300pp describing the language, arbitrary behaviors, and extraneous tools to go along with it
+- the solvable blockers
+  - no easy way to handle errors;
+    it can mean the life or death of a system with a misspelling
+  - not-so-good framework for asynchronous jobs;
+    performance is acceptable for single-threaded systems but not for multi-threaded ones;
+    that said, it does exist once you've made yourself familiar with it
+  - redudant computation;
+    several tools like [[roam:GNU Make]] does address it but not fully
+  - not exactly fitting with the modern deployment systems
+- some projects to look forward to
+  - Jash
+  - Smoosh
+  - Posh and Pash