blag/posts/2017-04-20-modularity.md
2017-04-22 11:42:36 -04:00

2.6 KiB

title, author, date, tags
title author date tags
Modularity (working title) Chris Hodapp April 20, 2017 technobabble
  • Nix, Guix

  • Notes - Distributed stuff notes (from turtl)

  • Notes - Paper, 2016-11-13

  • See notes on functional geekery #75

  • Jupyter

  • Any Plan 9 papers? (Will have to dig deep in the archives)

  • Tanenbaum vs. Linus war & microkernels

  • Abstraction vs. modularity

    • tbl_design quote: "Modular design hinges on the simplicity and abstract nature of the interface definition between the modules. A design in which the insides of each module need to know all about each other is not a modular design but an arbitrary partitioning of the bits."
  • Modules: Most useful when available in the most general or most accessible context, versus more specific, more restricted contexts? (e.g. Linux commandline tool vs. a Wordpress plugin or an Emacs package) - the TBL quote on least-power sort of corroborates this.

  • hypothes.is is a sort of module unto itself here too, trying to remove commenting and annotation from existing, very siloed solutions.

  • "Self" paper & structural reification?

  • What by Rich Hickey?

  • SICP?

  • "On Understanding Data Abstraction, Revisited"

  • Frameworks Don't Compose (composition)

  • Abstraction enables modularity. Why: Abstraction barriers are what separate modules.

  • The modules that make sense may change over time. ("Have modern tools tried to keep embodying the 'Unix philosophy'? Have they extended it, even to other forms of abstraction that weren't previously considered?")