Write some more on modularity draft
This commit is contained in:
Chris Hodapp
parent
4b6ba97e1b
commit
245047157e
@ -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
|
||||
to a more sensible abstraction. "Factoring out" is really a form of
|
||||
decoupling in which smaller parts of something are turned into a
|
||||
module which the original thing then interfaces with (one canonical
|
||||
example is taking some bits of code, often that are very similar or
|
||||
identical in many places, and moving them into a single function). To
|
||||
say one has "abstracted over" some details implies that a module is
|
||||
handling those details, that the details shouldn't matter, and what
|
||||
does matter is the abstraction one is using.
|
||||
(sometimes, creating them in the first place), typically splitting
|
||||
things into two more sensible pieces that a more sensible abstraction
|
||||
separates. "Factoring out" is really a form of decoupling in which
|
||||
smaller parts of something are turned into a module which the original
|
||||
thing then interfaces with (one canonical example is taking some bits
|
||||
of code, often that are very similar or identical in many places, and
|
||||
moving them into a single function). To say one has "abstracted over"
|
||||
some details implies that a module is handling those details, that the
|
||||
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
|
||||
a module unto itself, presumably it is relying on specific
|
||||
abstractions, and it is possible to move this module to other contexts
|
||||
(anything providing the same abstractions) or to replace it with other
|
||||
modules (anything using the same abstractions).
|
||||
It has a very pragmatic reason behind it: When something is a module
|
||||
unto itself, presumably it is relying on specific abstractions, and it
|
||||
is possible to freely change this module's internal details (provided
|
||||
that it still handles the same abstractions), to move this module to
|
||||
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
|
||||
instance, I can let the interpreter run on my much faster workstation,
|
||||
but I can access it across the Internet from my much slower laptop.
|
||||
produced them. Jupyter adds some other use-cases I find marvelous -
|
||||
for instance, I can let the interpreter run on my much faster
|
||||
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
|
||||
C or C++ compiler. It's purposely very easy both to *embed* (i.e. to
|
||||
put inside of a program and use as an extension language, such as for
|
||||
plugins or scripting) and to *extend* (i.e. to connect with libraries
|
||||
to allow their functionality to be used from Lua). [[https://www.gnu.org/software/guile/][GNU Guile]] has many
|
||||
of the same properties, I'm told.
|
||||
clean C with minimal dependencies, so it runs nearly anywhere that a C
|
||||
or C++ compiler targets. It's purposely very easy both to *embed*
|
||||
(i.e. to put inside of a program and use as an extension language,
|
||||
such as for plugins or scripting) and to *extend* (i.e. to connect
|
||||
with libraries to allow their functionality to be used from Lua). [[https://www.gnu.org/software/guile/][GNU
|
||||
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,14 +296,48 @@ 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://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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user