modularity
Last tended to 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”…
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)
emacs as a playground (emacs provides an powerful set of primitives for editing text)
so, one reason i like emacs is that it provides an incredibly powerful set of primitives for editing text. these primitives are not just confined to the ’writing app’ or the ’coding app’ (though there is not really such a thing as an ‘app’ in emacs), but rather they are present throughout the whole system. kinda like how cmd-C and cmd-V work in every app, but generalized.
examples:
you have primitives for things like deleting, uppercasing, highlighting, jumping up and down, creating a new line, recording a sequence of actions and replaying those back later…all the things that would be useful when editing text. and each of these primitives can be applied dynamically to a range of characters
but then, perhaps even cooler, is that these primitives are like LEGO blocks, or maybe more aptly described like Play-Doh. they can be molded, composed, replaced, or extended into anything the end-user.
- don’t like the default keybindings? (like vim’s better, as i do?) you can change them.
- you can set up a primitive that calls any external API, too. one example i like is github copilot, the AI code completion engine that i use. since everything in emacs is text, and copilot is an engine for text completion, by simply setting up copilot, we automagically get copilot in our code files, in our note files, in our terminal shell, and anywhere else we want it.
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)
emacs as a playground (emacs provides an powerful set of primitives for editing text)
so, one reason i like emacs is that it provides an incredibly powerful set of primitives for editing text. these primitives are not just confined to the ’writing app’ or the ’coding app’ (though there is not really such a thing as an ‘app’ in emacs), but rather they are present throughout the whole system. kinda like how cmd-C and cmd-V work in every app, but generalized.
examples:
you have primitives for things like deleting, uppercasing, highlighting, jumping up and down, creating a new line, recording a sequence of actions and replaying those back later…all the things that would be useful when editing text. and each of these primitives can be applied dynamically to a range of characters
but then, perhaps even cooler, is that these primitives are like LEGO blocks, or maybe more aptly described like Play-Doh. they can be molded, composed, replaced, or extended into anything the end-user.
- don’t like the default keybindings? (like vim’s better, as i do?) you can change them.
- you can set up a primitive that calls any external API, too. one example i like is github copilot, the AI code completion engine that i use. since everything in emacs is text, and copilot is an engine for text completion, by simply setting up copilot, we automagically get copilot in our code files, in our note files, in our terminal shell, and anywhere else we want it.