modularity
Last modified on May 14, 2022
I think it can be really good. Fairly related to compositionality. Will have to hash out what I think the difference is there.
♏️ emacs gets a lot of its power from its modularity. Packages are just little pieces of code– you can add/remove them into your ecosystem as you please. As opposed to proprietary software, where you may be much more limited in the customization that you can do…one piece of functionality for Evernote might not carry over to VSCode might not carry over to your web browser. etc.
^it’s beautiful chaos sometimes, though! Modules designed by tens of thousands of independent humans are bound to be overlapping, redundant, and sometimes confusing to “glue together”…
Despite reading explanations and guides occasionally, I’ve never understood how Org, BibTeX, org-ref, ebib, etc. all work together. I once tried to set them up using BibTeX references in a file, but I wasn’t able to figure out how to get citations working. I ran out of time to fiddle with it and had to do all the citations manually. :(
Well… They do not. It’s up to the end users glue them together. Bib(La)TeX only take care of record books&c references in a textual flat-file database, org-ref is mostly a helper to add things to that text db and quickly link a record in an org documents, helm-bibtex or ivy-bibtex are the search-based UI to operate with.
But luckily emacs has a great community that has helped smooth out the rough edges between packages, and even make them work together to make emacs a better place.
But….is the brain modular? I think it might not quite work that way.
Links to “modularity”
humor
what is humor? things that are unexpected, but in a “humorous” way? Ok, that’s tautological. But still. definitely something that I want to think about, notes I’m actively working on.
As a kind of meta example, while I’m here writing this note in emacs, I found myself naturally laughing at the fact that org-mode interpets the + signs in the encrypted PGP message in my org-journal files as a strikethrough, so parts of the PGP message are struck through. Even though strikethrough and org-crypt are both bona fide features of org, no one really noticed this little harmless, unintended interaction between the two (huh, there’s the connection to modularity!). Lmao.
Figure 1: Hey, if you figure out how to decrypt it, you can read what secrets I told to my journal today!
is it always optimal to compartmentalize / solve one problem at a time? Are there times when we might want to solve multiple problems simultaneously? (is it always optimal to compartmentalize / solve one problem at a time? Are there times when we might want to solve multiple problems simultaneously?)
thinking about this in relation to dynamic programming – I think it serves as a good metaphor for why it can be useful to think about the structure of the problems you’re solving, and if there’s any overlap / reuse that can occur….seems that this is also related to decomposition / modularity
“Flat” design (monorepo) vs. hierarchical? (“Flat” design (monorepo) vs. hierarchical?)
Aka, is modularity good?
For example, monorepo vs. structured w/ nice neat folders. Monorepo is easier to just scan and find what you want, simply use the power of search, but can get out of control if too large. OTOH, there is a strong argument for decomposition into folders/branches/etc. Also, when making text notes, should I have big, sprawling things like thoughts or small, decomposed things? (Ideal answer: both)
Links to “modular”
humor
what is humor? things that are unexpected, but in a “humorous” way? Ok, that’s tautological. But still. definitely something that I want to think about, notes I’m actively working on.
As a kind of meta example, while I’m here writing this note in emacs, I found myself naturally laughing at the fact that org-mode interpets the + signs in the encrypted PGP message in my org-journal files as a strikethrough, so parts of the PGP message are struck through. Even though strikethrough and org-crypt are both bona fide features of org, no one really noticed this little harmless, unintended interaction between the two (huh, there’s the connection to modularity!). Lmao.
Figure 2: Hey, if you figure out how to decrypt it, you can read what secrets I told to my journal today!
is it always optimal to compartmentalize / solve one problem at a time? Are there times when we might want to solve multiple problems simultaneously? (is it always optimal to compartmentalize / solve one problem at a time? Are there times when we might want to solve multiple problems simultaneously?)
thinking about this in relation to dynamic programming – I think it serves as a good metaphor for why it can be useful to think about the structure of the problems you’re solving, and if there’s any overlap / reuse that can occur….seems that this is also related to decomposition / modularity
“Flat” design (monorepo) vs. hierarchical? (“Flat” design (monorepo) vs. hierarchical?)
Aka, is modularity good?
For example, monorepo vs. structured w/ nice neat folders. Monorepo is easier to just scan and find what you want, simply use the power of search, but can get out of control if too large. OTOH, there is a strong argument for decomposition into folders/branches/etc. Also, when making text notes, should I have big, sprawling things like thoughts or small, decomposed things? (Ideal answer: both)