Merge branch 'master' of ssh://hodapple.com/home/hodapp/blag

drafts/2017-04-20-modularity.org

@@ -3,6 +3,9 @@
 #+DATE: April 20, 2017
 #+TAGS: technobabble
 
+# Why don't I turn this into a paper for arXiv too?  It can still be
+# posted to the blog (just also make it exportable to LaTeX perhaps)
+
 _Modularity_ and _abstraction_ feature prominently wherever computers
 are involved.  This is meant very broadly: it applies to designing
 software, using software, integrating software, and to a lot of
@@ -98,15 +101,16 @@ Other terms are related too.  "Loosely-coupled" (or loose coupling)
 and "tightly-coupled" refer to the sort of abstractions sitting
 between modules, or whether or not there even are separate modules.
 "Decoupling" involves changing the relationship between modules
-(sometimes, creating them in the first place), typically moving things
+(sometimes, creating them in the first place), typically splitting
-to a more sensible abstraction.  "Factoring out" is really a form of
+things into two more sensible pieces that a more sensible abstraction
-decoupling in which smaller parts of something are turned into a
+separates.  "Factoring out" is really a form of decoupling in which
-module which the original thing then interfaces with (one canonical
+smaller parts of something are turned into a module which the original
-example is taking some bits of code, often that are very similar or
+thing then interfaces with (one canonical example is taking some bits
-identical in many places, and moving them into a single function).  To
+of code, often that are very similar or identical in many places, and
-say one has "abstracted over" some details implies that a module is
+moving them into a single function).  To say one has "abstracted over"
-handling those details, that the details shouldn't matter, and what
+some details implies that a module is handling those details, that the
-does matter is the abstraction one is using.
+details shouldn't matter, and what does matter is the abstraction one
+is using.
 
 # -----
 Consider the information this module deals in, in essence.
@@ -134,13 +138,14 @@ module (from what was factored out) and some number of abstractions
   application itself is a module of a different sort.  (Witness that
   sometimes another application will implement the same plugin API.)
 
-One reason behind this is more practical in nature: When something is
+It has a very pragmatic reason behind it: When something is a module
-a module unto itself, presumably it is relying on specific
+unto itself, presumably it is relying on specific abstractions, and it
-abstractions, and it is possible to move this module to other contexts
+is possible to freely change this module's internal details (provided
-(anything providing the same abstractions) or to replace it with other
+that it still handles the same abstractions), to move this module to
-modules (anything using the same abstractions).
+other contexts (anything providing the same abstractions), to replace
+it with other modules (anything using the same abstractions).
 
-Another reason is more abstract: When something is a module unto
+It also has a more abstract reason: When something is a module unto
 itself, the way it is designed and implemented often presents more
 insight into the fundamentals of the problem it is solving. It
 contains fewer incidental details, and more essential details.
@@ -172,9 +177,10 @@ interface (similar to something like Maple or Mathematica) which:
 I love notebook interfaces already because they simplify experimenting
 by handling a lot of things I'd otherwise have to do manually - like
 saving results and keeping them lined up with the exact code that
-produced them.  Jupyter adds some other use-cases find marvelous - for
+produced them.  Jupyter adds some other use-cases I find marvelous -
-instance, I can let the interpreter run on my much faster workstation,
+for instance, I can let the interpreter run on my much faster
-but I can access it across the Internet from my much slower laptop.
+workstation, but I can access it across the Internet from my much
+slower laptop.
 
 [[https://zeppelin.apache.org/][Apache Zeppelin]] does similar things with different languages; I just
 use it less.
@@ -187,12 +193,12 @@ programming-language specific package managers into a single module is
 a very lofty goal, but Nix appears to do a decent job of it.
 
 The [[https://www.lua.org/][Lua]] programming language is noteworthy here.  It's written in
-clean C with minimal dependencies, so it runs nearly anyplace with a a
+clean C with minimal dependencies, so it runs nearly anywhere that a C
-C or C++ compiler.  It's purposely very easy both to *embed* (i.e. to
+or C++ compiler targets.  It's purposely very easy both to *embed*
-put inside of a program and use as an extension language, such as for
+(i.e. to put inside of a program and use as an extension language,
-plugins or scripting) and to *extend* (i.e. to connect with libraries
+such as for plugins or scripting) and to *extend* (i.e. to connect
-to allow their functionality to be used from Lua).  [[https://www.gnu.org/software/guile/][GNU Guile]] has many
+with libraries to allow their functionality to be used from Lua).  [[https://www.gnu.org/software/guile/][GNU
-of the same properties, I'm told.
+Guile]] has many of the same properties, I'm told.
 
 We ordinarily think of object systems as something living in the
 programming language.  However, the object system is sometimes made a
@@ -203,6 +209,19 @@ particularly if you allow dead ones created during the object-oriented
 hype of the '90s.  This seems to happen in systems where the object
 hierarchy is in effect "bigger" than the language.
 
+ZeroMQ is also notable here (and I know it's likely not unique, but it
+is one of the better-known and the first I thought of) as a set of
+cross-language abstractions for communication patterns.
+
+Interestingly, the same iMatix behind ZeroMQ also created [[https://github.com/imatix/gsl][GSL]] and
+explained its value in [[https://imatix-legacy.github.io/mop/introduction.html][Model-Oriented Programming]], for which
+abstraction features heavily.  I've not used GSL, and am skeptical of
+its stated usefulness, but it looks like it is meant to help create
+compile-time abstractions that likewise sit outside of any particular
+programming language.
+
+# TODO: Expand on this.
+
 [[https://web.hypothes.is/][hypothes.is]] is a curious one that I find fascinating.  They're trying
 to factor out annotation and commenting from something that is handled
 on a per-webpage basis and turn it into its own module, and I really
@@ -217,6 +236,11 @@ mention...
 
 # ???
 
+# Also, TCP/IP and the entire notion of packet-switched networks.
+# And the entire OSI 7-layer model.
+
+# Also, caches - of all types.  (CPU, disk...)
+
 People know that I love Emacs, but I also do believe many of the
 complaints on how large it is.  On the one hand, it is basically its
 own operating system and /within this/ it has considerable modularity.
@@ -262,7 +286,9 @@ https://github.com/stevemao/left-pad/issues/4
   powerful. The reason for this is that the less powerful the
   language, the more you can do with the data stored in that
   language. If you write it in a simple declarative from, anyone can
-  write a program to analyze it in many ways."
+  write a program to analyze it in many ways."  (Languages are a kind
+  of abstraction - one that influences how a module is written, and
+  what contexts it is useful in.)
 - "Self" paper & structural reification?
   - I'm still not sure how this relates, but it may perhaps relate to
     how *not* to make things modular (structural reification is a sort
@@ -270,18 +296,22 @@ https://github.com/stevemao/left-pad/issues/4
 - What by Rich Hickey?
   - Simple Made Easy?
   - The Value of Values?
-- SICP: [[https://mitpress.mit.edu/sicp/full-text/sicp/book/node50.html][Modularity, Objects, and State]]
+- SICP: [[https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-19.html#%25_chap_3][Modularity, Objects, and State]]
 - [[https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf][On Understanding Data Abstraction, Revisited]]
 - http://www.catb.org/~esr/writings/taoup/html/apb.html#Baldwin-Clark -
   Carliss Baldwin and Kim Clark. Design Rules, Vol 1: The Power of
   Modularity. 2000. MIT Press. ISBN 0-262-024667.
 - Brooks, No Silver Bullet?
+
 - https://en.wikipedia.org/wiki/Essential_complexity
 
 - https://twitter.com/fchollet/status/962074070513631232
 
 - How does this fit with /composition/? Does it?
-
+  - The ability to sensibly compose things depends on them having some
+    sort of well-defined, compatible boundary - right?
+  - Note also /decomposition/ here, as in /decomposing/ something into
+    parts.
 - [[https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book-Z-H-9.html#%25_chap_1][From SICP chapter 1 intro]]: "The acts of the mind, wherein it exerts
   its power over simple ideas, are chiefly these three: 1. Combining
   several simple ideas into one compound one, and thus all complex
@@ -292,3 +322,32 @@ https://github.com/stevemao/left-pad/issues/4
   from all other ideas that accompany them in their real existence:
   this is called abstraction, and thus all its general ideas are
   made." -John Locke, An Essay Concerning Human Understanding (1690)
+- [[https://en.wikipedia.org/wiki/Cross-cutting_concern][Cross-cutting concerns]], [[https://en.wikipedia.org/wiki/Aspect-oriented_programming][aspect-oriented programming]] (as an attempt
+  to take tangled things and pull them into modules)
+  - [[https://en.wikipedia.org/wiki/Separation_of_concerns][Separation of Concerns]]
+- Abstraction as an information channel... module as a what?
+- Even in DOS days, simple abstractions mattered like making something
+  behave like a hard drive or like a filesystem in DOS.  Things like
+  DriveSpace/DoubleSpace/Stacker worked well enough because most
+  applications were written to respect DOS's file access calls.
+  Things like HIMEM, EMM386, and QEMM worked reasonably well because
+  applications were written to respect DOS's dumpster fire of memory
+  management that I am eternally lucky to never have to touch again.
+- One point I have ignored (maybe): You clearly separate the 'inside'
+  of a module (its implementation) from the 'outside' (that is - its
+  boundaries, the abstractions that it interfaces with or that it
+  implements) so that the 'inside' can change more or less freely
+  without having any effect on the outside.
+- Abstractions as _contracts_ with a communicated/agreed purpose
+- Abstractions as a way of reducing the work required to add
+  functionality (changes can be made just in the relevant modules, and
+  other modules do not need to change to conform)
+- What is more key?  Communication, information content, contracts,
+  details?
+- [[https://en.wikipedia.org/wiki/Abstraction_principle_(computer_programming)][Abstraction principle]]
+  - Reduce duplication of information
+  - [[https://en.wikipedia.org/wiki/Don%2527t_repeat_yourself][Don't repeat yourself]]
+- [[https://simplyphilosophy.org/study/aristotles-definitions/][Aristotle & theory of definitions]]
+  - this isn't right.  I need to find the quote in the Durant book
+    (which will probably have an actual source) that pertains to how
+    specific and how general a definition must be