From 115d8142cc8777e0caa26867c6eb1b292bd60cf3 Mon Sep 17 00:00:00 2001
From: Blaise Thompson <blaise@untzag.com>
Date: Mon, 2 Apr 2018 20:56:06 -0500
Subject: 2018-04-02 20:56

---
 software/chapter.tex | 102 +++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 91 insertions(+), 11 deletions(-)

(limited to 'software/chapter.tex')

diff --git a/software/chapter.tex b/software/chapter.tex
index 8bc81af..83fd207 100644
--- a/software/chapter.tex
+++ b/software/chapter.tex
@@ -119,12 +119,14 @@ of researchers and a contracted team of software engineers.  %
 
 \subsection{Testing}  % ---------------------------------------------------------------------------
 
-PrabhuPrakash2011a---lots of good stuff under ``Scientists do not rigorusly test their programs''
+PrabhuPrakash2011a---lots of good stuff under ``Scientists do not rigorously test their programs''
 
 \subsection{Lifetime}  % --------------------------------------------------------------------------
 
 PrabhuPrakash2011a--- subsection ``long history of software development''
 
+Challenges with portability, and updating to ``modern standards''.
+
 \subsection{Optimization}  % ----------------------------------------------------------------------
 
 PrabhuPrakash2011a: ``scientists do not optimize for the common case'', ``scientists are unaware of
@@ -132,29 +134,35 @@ parallelization paradigms''
 
 \subsection{Maintenance}  % -----------------------------------------------------------------------
 
+Scientific software, especially software maintained by graduate students, tends to be very hard to
+maintain.  %
+This problem is compounded by the long lifetime of such software, and the poorly defined
+requirements and lack of documentation and testing.  %
+Often times, scientific software ends up being a mess of layer upon layer of incongruent pieces
+written by generation upon generation of student.  %
+Worse, software is sometimes abandoned or left untouched to become a crucial but arcane component
+of a scientific research project.  %
+
 \section{Good-enough practices}  % ================================================================
 
 In their [...] perspective, ``Good enough practices in scientific computing'', (from which this
 section gets its name) [WILSON ET AL] describe a set of techniques that, in their words, ``every
 researcher can and should consider adopting''.  %
 
+\subsection{Write clearly and document often}  % --------------------------------------------------
+
 Let the computer do the work...
 
 Write programs for people, not computers.  %
 
+\subsection{Do not reinvent}  % -------------------------------------------------------------------
+
 Don't repeat yourself, or others (we built on top of scipy, hdf5).
 
-Plan for mistakes / use testing.
+\subsection{Avoid premature optimization}  % ------------------------------------------------------
 
 Write first, optimize later.
 
-Document document docuement.
-
-Collaborate.
-Code review...
-Issues...
-Make incremental changes...
-
 \subsection{Data formats}  % ----------------------------------------------------------------------
 
 % HDF5
@@ -163,10 +171,82 @@ Make incremental changes...
 
 % OBJECT ORIENTED PROGRAMMING
 
-\subsection{Version control}  % -------------------------------------------------------------------
+\subsection{Collaboration and version control}  % -------------------------------------------------
+
+Plan for mistakes / use testing.
+
+Document document docuement.
+
+Collaborate.
+Code review...
+Issues...
+Make incremental changes...
 
 % SOURCE CONTROL AND VERSIONING
 
 \subsection{Licensing and distribution}  % --------------------------------------------------------
 
-% LICENSING AND DISTRIBUTION
\ No newline at end of file
+% LICENSING AND DISTRIBUTION
+
+\section{Object oriented programming}  % ----------------------------------------------------------
+
+The work in this dissertation makes heavy use of object oriented programming, so some very basic
+introduction to the concept seems warranted.  %
+Object oriented programming (OOP) is a \emph{programming paradigm}.  %
+Other popular paradigms are procedural programming and functional programming.  %
+Python is a popular programming language which allows for OOP.  %
+This section will discuss OOP in the context of a Python implementation.  %
+
+The basic idea of OOP is defining object types (classes) that are self-contained.  %
+These classes define pieces of associated data (attributes) and associated procedures (functions)
+within themselves.  %
+Once the class is defined, instances of that class are created.  %
+Instances, as the name implies, are just specific ``concrete occurance'' of a given class.  %
+The classic example: \python{Dog} is a class, \python{fido}, \python{spot}, and \python{duke} are
+three dogs---three instances of the dog class.  %
+
+OOP is easier to demonstrate than explain, so let's have some fun with some working Python
+examples.  %
+First, we will define a class.  %
+\begin{codefragment}{python}
+class Person():
+
+    def __init__(self, name, favorite_food=None, hated_food=None):
+        self.name = name
+        self.favorite_food = favorite_food
+        self.hated_food = hated_food
+
+    def react_to(self, food):
+        if food == self.favorite_food:
+            return 'yum! my favorite'
+        elif food == self.hated_food:
+            return 'gross---no thank you'
+        else:
+            return 'meh'
+\end{codefragment}
+Now I can make some instances of that class, and access their attributes and methods.  %
+\begin{codefragment}{python}
+>>> mary = Person(name='Mary', favorite_food='pizza', hated_food='falafel')
+>>> jane = Person(name='Jane', favorite_food='salad')
+>>> mary.react_to('falafel')
+'gross---no thank you'
+>>> jane.react_to('salad')
+'yum! my favorite'
+>>> mary.favorite_food
+'pizza'
+>>> jane.react_to(mary.favorite_food)
+'meh'
+\end{codefragment}
+To the knowledge of this author
+
+\section{Hierarchical data format}  % -------------------------------------------------------------
+
+FITS
+
+HDF5
+
+CDF (Common Data Format)
+
+\section{Scientific Python}  % --------------------------------------------------------------------
+
+Numpy, SciPy
\ No newline at end of file
-- 
cgit v1.2.3

