modularity post: Wrote a bit more, tried to clean things up

This commit is contained in:
Chris Hodapp 2018-04-08 09:51:45 -04:00
parent d61191c390
commit 2488406615

View File

@ -39,9 +39,13 @@ bits... It is not only necessary to make sure your own system is
designed to be made of modular parts. It is also necessary to realize
that your own system, no matter how big and wonderful it seems now,
should always be designed to be a part of another larger system." Les
Hatton in [[http://www.leshatton.org/TAIC2008-29-08-2008.html][The role of empiricism in improving the reliability of future software]]
even did an interesting derivation tying the defect
density in software to how it is broken into pieces.
Hatton in [[http://www.leshatton.org/TAIC2008-29-08-2008.html][The role of empiricism in improving the reliability of
future software]] even did an interesting derivation tying the defect
density in software to how it is broken into pieces. The 1972 paper
[[https://www.cs.virginia.edu/~eos/cs651/papers/parnas72.pdf][On the Criteria to be Used in Decomposing System into Modules]] cites a
1970 textbook on why modularity is important in systems programming,
but also notes that nothing is said on how to divide a systems into
modules.
"Abstraction" doesn't have quite the same consensus. In software, it's
generally understood that decoupled or loosely-coupled is better than
@ -136,7 +140,7 @@ 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).
Another reason is more abstract: When something it a module unto
Another reason is more abstract: 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.
@ -152,7 +156,7 @@ problems that I wasn't even aware existed.
[[https://circleci.com/blog/it-really-is-the-future/][It really is the future]] talks about a lot of more recent forms of
modularity, most of which are beyond me and were completely unheard-of
in, say, 2010. [[https://www.functionalgeekery.com/episode-75-eric-b-merritt/][Functional Geekery episode 75]] talks about many similar
things
things.
[[https://jupyter.org/][Jupyter Notebook]] is one of my favorites here. It provides a notebook
interface (similar to something like Maple or Mathematica) which:
@ -188,12 +192,21 @@ 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.
of the same properties, I'm told.
[[https://web.hypothes.is/][hypothes.is]] is a curious one that I find fascinating. In effect,
they're trying to factor out annotation and commenting from something
that is handled on a per-webpage basis, and I really like what I've
seen.
We ordinarily think of object systems as something living in the
programming language. However, the object system is sometimes made a
module that is outside of the programming language, and languages just
interact with it. [[https://en.wikipedia.org/wiki/GObject][GObject]], [[https://en.wikipedia.org/wiki/Component_Object_Model][COM]], and [[https://en.wikipedia.org/wiki/XPCOM][XPCOM]] do this, and to some
extent, so does [[https://en.wikipedia.org/wiki/Meta-object_System][Qt & MOC]] - and there are probably hundreds of others,
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.
[[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
like what I've seen.
The Unix tradition lives on in certain modern tools. [[https://stedolan.github.io/jq/][jq]] has proven
very useful anytime I've had to mess with JSON data. [[http://www.dest-unreach.org/socat/][socat]] and [[http://netcat.sourceforge.net/][netcat]]
@ -206,10 +219,24 @@ mention...
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, there is a perfectly usable operating system
underneath, and this makes me wonder why it needs explicit support for
[[https://www.gnu.org/software/tramp/][network transparency]].
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.
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
re-read regularly. Large parts of the paper are about ways in which
machine learning conflicts with proper modularity and abstraction.
(However, [[https://colah.github.io/posts/2015-09-NN-Types-FP/][Neural Networks, Types, and Functional Programming]] is still
a good post and shows some sorts of abstraction that still exist
at least in neural networks.)
[[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.
Submitted without further comment:
https://github.com/stevemao/left-pad/issues/4
* Fragments
@ -222,6 +249,7 @@ underneath, and this makes me wonder why it needs explicit support for
- [[Notes - Paper, 2016-11-13]]
- Any Plan 9 papers? (Will have to dig deep in the archives)
- http://plan9.bell-labs.com/sys/doc/
- Link is now down
- Tanenbaum vs. Linus war & microkernels
- TBL: "The choice of language is a common design choice. The low
power end of the scale is typically simpler to design, implement and
@ -243,21 +271,13 @@ underneath, and this makes me wonder why it needs explicit support for
- Simple Made Easy?
- The Value of Values?
- SICP: [[https://mitpress.mit.edu/sicp/full-text/sicp/book/node50.html][Modularity, Objects, and State]]
- "On Understanding Data Abstraction, Revisited"
- "On the Criteria to be Used in Decomposing System into Modules" (Barnas)
- [[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.
- https://colah.github.io/posts/2015-09-NN-Types-FP/ - Was this the
one that talked about 'modularity' in deep learning?
- [[https://clojurefun.wordpress.com/2012/08/17/composition-over-convention/][Frameworks Don't Compose]]
- Brooks, No Silver Bullet?
- https://www.reddit.com/r/programming/comments/4bjss2/an_11_line_npm_package_called_leftpad_with_only/
- http://www.freecode.com/articles/editorial-the-two-edged-sword
- https://en.wikipedia.org/wiki/Essential_complexity
- GObject framework: an object system that sits outside of any
particular language (though this is nothing particularly new)
- libgreen
- https://twitter.com/fchollet/status/962074070513631232
- How does this fit with /composition/? Does it?