Misc rewording in modularity post

drafts/2017-04-20-modularity.org

@@ -10,7 +10,7 @@ _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
 hardware as well.  It applies elsewhere, and almost certainly
-originated there first, however, it appears to be particularly
+originated elsewhere first, however, it appears to be particularly
 crucial around software.
 
 Definitions, though, are a bit vague (including anything in this
@@ -19,19 +19,28 @@ explain a bit of their essence, and expand on a few theses:
 
 - Modularity arises naturally in a wide array of places.
 - Modularity and abstraction are intrinsically connected.
-- Whether a given modularization makes sense depends strongly on
-  meaning and relevance of *information* inside and outside of
-  modules, and broad context matters to those.
+- Both are for the benefit of people.  This usually doesn't need
+  stated, but to echo Paul Graham and probably others: to the
+  computer, it is all the same.
+- More specifically, both are there to manage *complexity* by
+  assigning meaningful information and boundaries which allow people
+  to match a problem to what they can actually think about.
+
+# - Whether a given modularization makes sense depends strongly on
+#  meaning and relevance of *information* inside and outside of
+#  modules, and broad context matters to those.
 
 * Why?
 
 People generally agree that "modularity" is good.  The idea that
 something complex can be designed and understood in terms of smaller,
 simpler pieces comes naturally to anyone that has built something out
-of smaller pieces or taken something apart.  It runs very deep in the
-Unix philosophy, which ESR gives a good overview of in [[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html][The Art of Unix
-Programming]] (or, listen to it from [[https://youtu.be/tc4ROCJYbm0?t%3D248][Kernighan himself]] at Bell Labs in
-1982.)
+of smaller pieces or taken something apart.  (This isn't to say that
+reductionism is the best way to understand everything, but that's
+another matter.)  It runs very deep in the Unix philosophy, which ESR
+gives a good overview of in [[http://www.catb.org/~esr/writings/taoup/html/ch01s06.html][The Art of Unix Programming]] - or, listen
+to it from [[https://youtu.be/tc4ROCJYbm0?t%3D248][Kernighan himself]] at Bell Labs in
+1982.
 
 Tim Berners-Lee gives some practical limitations in [[https://www.w3.org/DesignIssues/Principles.html][Principles of
 Design]] and in [[https://www.w3.org/DesignIssues/Modularity.html][Modularity]]: "Modular design hinges on the simplicity and
@@ -209,9 +218,10 @@ 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.
+ZeroMQ is another example as a set of cross-language abstractions for
+communication patterns in a distributed system.  I know it's likely
+not unique, but it is one of the better-known and the first I thought
+of, and I think their [[http://zguide.zeromq.org/page:all][guide]] is excellent.
 
 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
@@ -241,12 +251,13 @@ mention...
 
 # Also, caches - of all types.  (CPU, disk...)
 
+# One key is how the above let you *reason* about things without
+# knowing their specifics.a
+
 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.
-On the other hand, I already have a perfectly usable operating system
-underneath, and it can make SSH tunnels instead of requiring that my
-editor have [[https://www.gnu.org/software/tramp/][its own explicit support]] for them.
+complaints on how large it is.  Despite that it is basically its own
+operating system, /within this/ it has considerable modularity.  The
+same applies somewhat to Blender, I suppose.
 
 Consider [[https://research.google.com/pubs/pub43146.html][Machine Learning: The High Interest Credit Card of Technical Debt]],
 a paper that anyone working around machine learning should read and
@@ -256,6 +267,22 @@ machine learning conflicts with proper modularity and abstraction.
 a good post and shows some sorts of abstraction that still exist
 at least in neural networks.)
 
+Even DOS presented useful abstractions.  Things like
+DriveSpace/DoubleSpace/Stacker worked well enough because most
+software that needed files relied on DOS's normal abstractions to
+access them - so it did not matter to them that the underlying
+filesystem was actually compressed, or in a RAM disk or whatever.
+Likewise, for the silliness known as [[https://en.wikipedia.org/wiki/Expanded_memory][EMS]], applications that accessed
+memory through the EMS abstraction could disregard whether it was a
+"real" EMS board providing access to that memory, whether it was an
+expanded memory manager providing indirect access to some other memory
+or even to a hard disk pretending to be memory.
+
+Even more abstractly: emulators work because so much software
+respected the abstraction of some specific CPU and hardware platform.
+
+# Does the below belong here? that isn't really an example.
+
 [[https://clojurefun.wordpress.com/2012/08/17/composition-over-convention/][Composition over convention]] is an important read on why /frameworks/
 can also run completely counter to modularity.
 
@@ -326,13 +353,6 @@ https://github.com/stevemao/left-pad/issues/4
   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