Write some more on modularity draft
This commit is contained in:
parent
4b6ba97e1b
commit
245047157e
@ -3,6 +3,9 @@
|
|||||||
#+DATE: April 20, 2017
|
#+DATE: April 20, 2017
|
||||||
#+TAGS: technobabble
|
#+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
|
_Modularity_ and _abstraction_ feature prominently wherever computers
|
||||||
are involved. This is meant very broadly: it applies to designing
|
are involved. This is meant very broadly: it applies to designing
|
||||||
software, using software, integrating software, and to a lot of
|
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
|
and "tightly-coupled" refer to the sort of abstractions sitting
|
||||||
between modules, or whether or not there even are separate modules.
|
between modules, or whether or not there even are separate modules.
|
||||||
"Decoupling" involves changing the relationship between 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.
|
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
|
application itself is a module of a different sort. (Witness that
|
||||||
sometimes another application will implement the same plugin API.)
|
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
|
itself, the way it is designed and implemented often presents more
|
||||||
insight into the fundamentals of the problem it is solving. It
|
insight into the fundamentals of the problem it is solving. It
|
||||||
contains fewer incidental details, and more essential details.
|
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
|
I love notebook interfaces already because they simplify experimenting
|
||||||
by handling a lot of things I'd otherwise have to do manually - like
|
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
|
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
|
[[https://zeppelin.apache.org/][Apache Zeppelin]] does similar things with different languages; I just
|
||||||
use it less.
|
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.
|
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
|
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
|
We ordinarily think of object systems as something living in the
|
||||||
programming language. However, the object system is sometimes made a
|
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
|
hype of the '90s. This seems to happen in systems where the object
|
||||||
hierarchy is in effect "bigger" than the language.
|
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
|
[[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
|
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
|
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
|
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
|
complaints on how large it is. On the one hand, it is basically its
|
||||||
own operating system and /within this/ it has considerable modularity.
|
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
|
powerful. The reason for this is that the less powerful the
|
||||||
language, the more you can do with the data stored in that
|
language, the more you can do with the data stored in that
|
||||||
language. If you write it in a simple declarative from, anyone can
|
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?
|
- "Self" paper & structural reification?
|
||||||
- I'm still not sure how this relates, but it may perhaps relate to
|
- 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
|
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?
|
- What by Rich Hickey?
|
||||||
- Simple Made Easy?
|
- Simple Made Easy?
|
||||||
- The Value of Values?
|
- 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]]
|
- [[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 -
|
- http://www.catb.org/~esr/writings/taoup/html/apb.html#Baldwin-Clark -
|
||||||
Carliss Baldwin and Kim Clark. Design Rules, Vol 1: The Power of
|
Carliss Baldwin and Kim Clark. Design Rules, Vol 1: The Power of
|
||||||
Modularity. 2000. MIT Press. ISBN 0-262-024667.
|
Modularity. 2000. MIT Press. ISBN 0-262-024667.
|
||||||
- Brooks, No Silver Bullet?
|
- Brooks, No Silver Bullet?
|
||||||
|
|
||||||
- https://en.wikipedia.org/wiki/Essential_complexity
|
- https://en.wikipedia.org/wiki/Essential_complexity
|
||||||
|
|
||||||
- https://twitter.com/fchollet/status/962074070513631232
|
- https://twitter.com/fchollet/status/962074070513631232
|
||||||
|
|
||||||
- How does this fit with /composition/? Does it?
|
- 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