More programmer nonsense Re: Atomicity - Writing and Thinking
I'm excited for the clarity of ideas I found, so here I want to share stuff from two seemingly distinct fields: programming and writing.
I'm aware that the following is not new. It's probably part of Plato's Collected Works, book 7 or so.
The elements of programming, according to Abelson and Sussman (Structure and interpretation of computer programs, 2nd edition, Cambridge, Mass.: MIT Press. (1996), page 4)
- Primitive Expressions: represent the simplest entities of the language;
- Means of Combination: building compound elements from simpler ones;
- Means of Abstraction: naming and manipulating compound elements as units.
When techies lament that everything is "abstractions upon abstractions", they lament the result of doing the process of combining small things into larger things, and then treating these larger things as new units which in turn can be combined to create a new composite. It goes the other way, too: you can pry open large units and see the smaller ones.
I've thought about these elements of programming, and also a book called Elements of Programming the past weeks. This was my frame of mind: technical, both analytical (thinking about pieces and identifying them) and creative (how to build larger systems, step by step, and aid the sensemaking).
Along came Oliver Reichenstein of iA with 50% of a (to me) interesting idea.
He linked an old blog post of his: The Ideal Paragraph. It's very short but has a couple of references, namely:
- Johnie H. Scott: Topic Sentence Paragraph https://www.csun.edu/~hcpas003/topic.html
- James Surowiecki: "One Thought Per Sentence", The New Yorker, 2008-11-17 https://www.newyorker.com/business/james-surowiecki/one-thought-per-sentence --- Surowiecki retells a Bloomberg rule to avoid 'but's in sentences so that readers don't have to keep conflicting ideas in mind. That's what "one thought per sentence" boils down to: to avoid conflict, state one thing, and one thing only, per sentence.
In his post, he references up the ideas of having one thought per paragraph and one thought per sentence.
I imagine this as two units on different levels: the paragraph, representing one idea, which is made of sentences, each representing one idea as well.
┌───────────────┐
│ Paragraph │ ───▶ Idea
└─┬─────────────┘
│ ┌──────────┐
├──┤ Sentence │ ───▶ Idea
│ └──────────┘
│ ┌──────────┐
├──┤ Sentence │ ───▶ Idea
│ └──────────┘
│ ┌──────────┐
└──┤ Sentence │ ───▶ Idea
└──────────┘
On Mastodon, Oliver mused about an ideal length of an article, and how long form writing needs to be denser. For context, he published a huge article recently, Unraveling the digital markets act, and found that short-form writing can get away with being chatty, but long-form writing needs to be dense because the length itself is an imposition already. (See around here https://mastodon.social/@reichenstein/110858524534665631 for reference)
The following leap of thought seemed obvious to me in my current frame of mind, but Oliver drifted off writing about rhythm and sentence lengths, missing to go the same way consequently in both directions: an article, and a longer piece of writing, should also be of one thought.
┌───────────────┐
│ Article │ ───▶ Idea
└─┬─────────────┘
│ ┌──────────┐
├──┤ Parag. │ ───▶ Idea
│ └──────────┘
│ ┌──────────┐
├──┤ Parag. │ ───▶ Idea
│ └──────────┘
│ ┌──────────┐
└──┤ Parag. │ ───▶ Idea
└──────────┘
After pointing that out, I processed his sources and systematized my idea a bit more.
Talking about 1 thingie per widget, or 1 X per Y, is a different way to talk about Atomicity.
My short summary is this:
1) Limit a unit to one thought.
2) Complex units represent complex thoughts.
3) Thoughts decompose into simpler thoughts, simple thoughts compose to form new abstractions.
4) Understanding requires decomposition (to follow along with something new), insight requires composition and abstraction (to grasp a complex idea as one idea).
It's the same old, same old: analysis/synthesis.
Analysis versus synthesis: contrasting both approaches, frames of mind, brain halves.
Analysis and synthesis: putting both tools under one's tool belt.
┌───────────────┐ ┌───────────────┐
│ Composite │ │ Sum │
└─┬─────────────┘ └─┬─────────────┘
│ ┌──────────┐ │ ┌──────────┐
├──┤ Unit │ ├──┤ Part │
│ └──────────┘ │ └──────────┘
│ ┌──────────┐ │ ┌──────────┐
├──┤ Unit │ ├──┤ Part │
│ └──────────┘ │ └──────────┘
│ ┌──────────┐ │ ┌──────────┐
└──┤ Unit │ └──┤ Part │
└──────────┘ └──────────┘
This can be nested, recursively.
Back to Zettelkasten, this is the unit-level pattern:
┌──────────┐ │ Zettel │ ───▶ Idea └──────────┘
Everything about writing applies still: articles should be about one thing (remember how Zettel should be blog posts? That's at least part of the German ZK book, 1st edition, and mentioned by @Sascha here and there); each paragraph should be about one thing, supporting its section/article/Zettel; and each sentence should be about one thing, supporting its paragraph.
Structure notes are atomic, too, because they group other notes under one banner for a reason, expressing a thought.
It's a larger level of abstraction -- that's how I think of it with the vocabulary of my craft. It's a larger unit comprised of smaller units, a writing project with many details, say, in the terms of a Zettler.
┌───────────────┐
│ Zettel │ ───▶ Idea
└─┬─────────────┘
│ ┌──────────┐
├──┤ Zettel │ ───▶ Idea
│ └──────────┘
│ ┌──────────┐
├──┤ Zettel │ ───▶ Idea
│ └──────────┘
│ ┌──────────┐
└──┤ Zettel │ ───▶ Idea
└──────────┘
This is where my exciting journey ends: I've left out cross-references to programming concepts like how to talk about composites and their coherence, which basically means "how well do the parts support the sum's existence". I'll milk this idea for a while longer. I've struggled with making a better "Atomicity" post than the 2014 one, and this feels good. But as Kent Beck says:
Optimism is an occupational hazard of programming: feedback is the treatment.
--- Kent Beck, Extreme Programming Explained : Embrace Change (2000)
So: feedback about the intelligibility of this idea is welcome 
I do recommend processing the linked sources for one's own ZK. They're not that long, but succinct and seem useful.
Edit 2023-08-10: Added the "Zettel → Idea" diagram at the end which I forgot to paste.
Author at Zettelkasten.de • https://christiantietze.de/
Howdy, Stranger!
Comments
These ideas are as magnificent as a convocation of eagles.
The juxtaposition of programming and writing brings to mind Donald Knuth's "Literate Programming (1984)" in Literate Programming. CSLI, 1992, pg. 99. Knuth's idea was that a program should tell a story, and the programmer should write that story into the program.
You bring up good points about atomicity. How might these be applied in programming? A class is defined as a single entity with functions as primary expressions, following the example of the "1 thingie per widget, or 1 X per Y".
Surprisingly, computer programs could be written so that humans can read them. (Maybe even enjoy reading them.)
Computer programming is an art in as much as it contributes to producing beauty worldwide. "A programmer who subconsciously views himself as an artist will enjoy what he does and do it better." 1
Knuth, Donald E. Computer Programming as an Art. no. 12, 1974, p. 10. ↩︎
Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
@Will
Knuth's literate programming is an interesting reference. Didn't think of that and literal mixing writing and coding in this case!
Since you're in the programming world yourself: you'll notice that people have been sharing principles of organization that extend the description "a class is an entity with functions as primary expressions" -- the Single Responsibility Principle, for example, which does not help find responsibilities in any way and extract them, but it does help to train the eye for opportunities when you begin to see that there's probably too many things mixed up in one place. Similarly, there are heuristics like "a piece of code should only have 1 reason to be changed".
So I'd say in an ideal world,
Classis not merely aGroup, like a basket of mixed vegetables, but it's a semantic unit itself, like a basket of ingredients for a soup.┌───────────────┐ │ Class │ ───▶ Idea (changed this) └─┬─────────────┘ │ ┌──────────┐ ├──┤ Function │ ───▶ Idea │ └──────────┘ │ ┌──────────┐ ├──┤ Function │ ───▶ Idea │ └──────────┘ │ ┌──────────┐ └──┤ Function │ ───▶ Idea └──────────┘And when the class expresses a singular idea and becomes a cohesive unit, then it can be composed into other things.
Author at Zettelkasten.de • https://christiantietze.de/
I realize I didn't explore the flip side:
Expressing a thought in a unit (sentence, paragraph, ...) is not like launching a rocket: you don't finish the process and then the thought is gone.
If everything's a thought, or idea, if done well (as I try to show in the diagrams), then the flip side is that each of these ideas are expressed by something, so the arrow should point both ways, because you can get from one to the other.
In the ZK example:
┌───────────────┐ │ Zettel │ ◀──▶ Idea └─┬─────────────┘ │ ┌──────────┐ ├──┤ Zettel │ ◀──▶ Idea │ └──────────┘ │ ┌──────────┐ ├──┤ Zettel │ ◀──▶ Idea │ └──────────┘ │ ┌──────────┐ └──┤ Zettel │ ◀──▶ Idea └──────────┘So focusing on "X expresses an idea" was the one direction of the arrow I presented above all the time.
If we focus on the flip side for a moment:
┌───────────────┐ Idea ───▶ │ Zettel │ └─┬─────────────┘ │ ┌──────────┐ Idea ───▶ ├──┤ Zettel │ │ └──────────┘ │ ┌──────────┐ Idea ───▶ ├──┤ Zettel │ │ └──────────┘ │ ┌──────────┐ Idea ───▶ └──┤ Zettel │ └──────────┘Then this can be read as: "each (expressed) idea can be found in a Zettel".
This is nothing new, either. @Sascha has been arguing wildly for the past years on the internet that, no, you're not actually interested in Zettel, you're interested in ideas. Zettel are just the means.
And so are sentences, and paragraphs:
┌─────────────────────────┐ Idea ───▶ │ Zettel │ └─┬───────────────────────┘ │ ┌────────────────────┐ Idea ───▶ ├──┤ Zettel │ │ └────────────────────┘ │ ┌────────────────────┐ Idea ───▶ ├──┤ Zettel │ │ └────────────────────┘ │ ┌────────────────────┐ Idea ───▶ └──┤ Zettel │ └─┬──────────────────┘ │ ┌───────────────┐ Idea ────────▶ ├──┤ Paragraph │ │ └───────────────┘ │ ┌───────────────┐ Idea ────────▶ ├──┤ Paragraph │ │ └───────────────┘ │ ┌───────────────┐ Idea ────────▶ └──┤ Paragraph │ └─┬─────────────┘ │ ┌──────────┐ Idea ─────────────▶ ├──┤ Sentence │ │ └──────────┘ │ ┌──────────┐ Idea ─────────────▶ ├──┤ Sentence │ │ └──────────┘ │ ┌──────────┐ Idea ─────────────▶ └──┤ Sentence │ └──────────┘Rephrasing the elements of programming: sentences and paragraphs are the units of idea-expressing, and the Zettel are compound units, which can be re-combined into new compound units.
So you don't have anything further on top, because it's same-ish from there on.
All 3 levels of analysis work with, operate on ideas.
If done well, you can drill down as needed to get to the details to understand the context, but the moment of having had insight is captured in the larger units, the compund units, the abstractions -- in the Zettel.
Author at Zettelkasten.de • https://christiantietze.de/
Thanks for the tutoring in the finer details of classes.
Random, unclear thoughts I want to try and make real.
1. The notion that an idea is expressed in a zettel and a zettel expresses an idea triggers a fragment of understanding. It is a two-way interaction. Writing to clarify the bilateral relationship will give the idea a fuller shape.
2. In the table below, structure notes should lead. Structure notes are the means of combination and abstraction of primitive expressions (zettel ideas.)
┌─────────────────────────┐ Idea ───▶ │ Structure Note │ └─┬───────────────────────┘ │ ┌────────────────────┐ Idea ───▶ ├──┤ Zettel │ │ └────────────────────┘ │ ┌────────────────────┐ Idea ───▶ ├──┤ Zettel │ │ └────────────────────┘ │ ┌────────────────────┐ Idea ───▶ └──┤ Zettel │ └────────────────────┘Will Simpson
My zettelkasten is for my ideas, not the ideas of others. I don’t want to waste my time tinkering with my ZK; I’d rather dive into the work itself. My peak cognition is behind me. One day soon, I will read my last book, write my last note, eat my last meal, and kiss my sweetie for the last time.
kestrelcreek.com
@ctietze: This is a good start. Let me bring in something I mentioned in a discussion last month: two figures from Maria Teresa Biagetti's article "Ontologies as knowledge organization systems" (in Knowledge Organization, 48(2), 2021, 152–176, and in the Encyclopedia of Knowledge Organization):
The level of precision of the model (or meta-model) you presented above is perhaps equivalent to the level of "classification scheme" in Figure 5.
One question you may want to consider is whether you want to take your model (or meta-model) to a higher level of precision ("higher" in terms of Biagetti's figures above) by bringing in more types of relationships and properties. (You said that you deliberately left this out: "I've left out cross-references to programming concepts like how to talk about composites and their coherence".) Max Völkel called this increase of precision adding formality, which he contrasted to adding structure and adding content: see Figure 3.4: "Knowledge cue augmentation processes" and Figure 3.5: "Knowledge cue life-cycle with collaboration" in Völkel's PhD thesis.1 Völkel's Figure 3.4 is similar to Biagetti's Figures 4 and 5.
I've mentioned before in this forum that I use a semantic schema (meta-model) in my note system inspired by IBIS. This is still a simple scheme but more complex than a hierarchical classification scheme. There are various schemes like this in argumentation theory.2 Joel Chan explored the idea that people naturally try to implement such typed distinctions in their notes because such "typing unlocks affordances that people find useful for their knowledge work".
Going back to Völkel's thesis mentioned above: Völkel proposed his own meta-model that he called Conceptual Data Structures (CDS),1 the formal definition of which "consists of atomic entities (NameItems, ContentItems) on top of which compound entities (Relations, Triples, Statements) are successively defined" (p. 133). Völkel gave his own definition of atomic entities: "The building blocks of CDS are addressable content units and unique names" (ibid.). I haven't analyzed how Völkel's model relates to @ctietze's model above, although generally speaking it clearly has a higher level of formality in Völkel's sense. I leave a more precise analysis as an exercise for the ambitious reader.
In summary: Talking in terms of "units that express ideas" gets the conversation started and explains in a helpfully simple way what Völkel called higher and lower levels of structure and content. But I would not want to end the explanation there without adding what Völkel called higher and lower levels of formality, because that third dimension of formality helps to clarify what the structure and content is for: why are you structuring content in one way instead of another way? Without a higher level of formality in Völkel's sense, you don't have an explicit answer to that question.
Max Völkel (2010). Personal Knowledge Models with Semantic Technologies. Zur Erlangung des akademischen Grades eines Doktors der Wirtschaftswissenschaften (Dr. rer. pol.) von der Fakultät für Wirtschaftswissenschaften des Karlsruher Instituts für Technologie (KIT) genehmigte Dissertation von Dipl.-Inform. ↩︎ ↩︎
Frans H. van Eemeren, Bart Garssen, Erik C. W. Krabbe, A. Francisca Snoeck Henkemans, Bart Verheij, & Jean H. M. Wagemans (2014). Handbook of Argumentation Theory (Revised edition). New York: Springer. ↩︎
Thank you for the pointers and ideas!
@Will
The dominating Structure Note as the paragon of expressing more complex thoughts/ideas does indeed follow from the thing written before, so I would tend to agree!
I'm hesitant to settle on this as a general rule, though, because leaving the general "Zettel" (or note) behind in favor of the more specific "Structure Note" in the table suggests that there's an inherent hierarchy. Yes, structure notes express structures and thus more complex thought. But that doesn't mean a non-structure note is unable to express a more complex thought based on many structure notes.
Imagine that after many structure notes on many different kinds of holy scripture, a flash of insight produces a note like this: "For all of history, men strife to make real the image of their inner perfection and reach some kind of salvation", plus links to the structure notes from which this idea spawned. This one-sentence summary (made up and not truly worth its weigh in gold, so imagine something even more profound!) is not a structure note, yet it is an abstraction that encapsulates insight gained from all kinds of scripture study.
So I'd say: it's always
Zettel → Zettel, and sometimes it'sStructure Note → Zettel, but sinceStructure Noteis also a Zettel, it's really just a special case of the former. And abstracting even more, it's ideas all the way down no matter how they are represented. -- But well, that's so abstract it's not useful on its own!100%! Reading this, I realized how bad my analogy was.
The rocket launch metaphor (or maybe even child-bearing?) is more than fire-and-forget. It's a lot of preparation to make sure things go well, but you never know, and once the vessel is out and about, you can't control it on its journey. It takes on a life of its own. You're right there!
@Andy Thanks for the references!
Approaching the way a mathematician would define closure under specific kinds of operations, while interesting to the programmer, doesn't help a ZK blog reader, so I'll not be exploring that at the moment.
But I do want to address problems of ergonomics, as in: where do I make a cut, where do I draw boundaries, and why? How does good boundary management differ from less ideal modularization?
Not sure how, yet. Völkel's 2010 PhD thesis is sitting, unprocessed, in my library since 2017. Guess I'll check that out and report back if it's truly as useful as you make it appear to be!
Author at Zettelkasten.de • https://christiantietze.de/
@ctietze said:
I agree: I don't see how that's relevant. I'm not much of a computer programmer, but I imagine that the parallel or overlap between computer-programming and knowledge-base concepts is very limited. You seem to be saying the same. More relevant is the area of information science that Völkel called semantic technology.
Perhaps instead of comparing only computer programming and writing composition, you should think of semantic technology as an intermediate domain, and diagram some relevant and irrelevant concepts in a Venn diagram of the three domains: computer programming, semantic technology, and writing composition.
I associate ergonomics more with physical efficiency and less with conceptual structures, but it's an interestingly unusual term to use for the latter. For problems of conceptual structures I would use terms like semantics (as in the aforementioned semantic technologies, not in the special sense of semantics of programming languages) and knowledge organization.
To provide context, it boils down to reducing friction in usage, which is a thing in writing code in recent years. Example: Rust's language ergonomics initiative: https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html
Should've clarified that, sorry!
Author at Zettelkasten.de • https://christiantietze.de/
@ctietze said:
Aha! Not being a (real) programmer, much less a programming language designer, I hadn't heard the term language ergonomics, which is a term specific to programming language design. I googled "language ergonomics" and quickly found at least a couple of sources (LangDev StackExchange, ProgrammingLanguages Reddit) that show that some people consider the term language ergonomics to be essentially equivalent to usability (of a programming language), which I would say is the more understandable term outside of programming. One of the Redditors quoted this passage from a Nielsen Norman Group article:
When I said that I would use terms like semantics and knowledge organization, I was thinking more about utility of conceptual structures for a personal knowledge base, but it's true that usability also is a very important aspect of the overall usefulness, to use the terms from the Nielsen Norman Group.
I need to fully process this thread. (Again: Best community in the www) Andy just throws in too much from too many directions.
(Which is a good thing)
I think the crucial point is the problem that no one knows what a single thought is.
I made a kind of template for an explanatory paragraph 10 years ago:
So. Next step: What is a thought?
I am a Zettler
@Sascha said:
I'm not sure if this is a joke that I should laugh at and ignore, or if I should continue throwing in stuff from too many directions?
There are theories of what a thought is. If I think that one of those theories is viable, then I can say that I know what a single thought is according to that theory.1
Around 1867, Charles Sanders Peirce (1839–1914) had a theory that thoughts are signs:
A few years later Peirce went on to become one of the inventors of predicate logic, which I suppose could be called a theory of how arguments can be constructed from thought-signs.2
Michael K. Bergman wrote a whole book that used Peirce's theory as the basis for a working knowledge representation system.3 I haven't read much of the book; I only mention it as an example of an application of a theory of thought to knowledge organization.
On the importance of theories in knowledge organization, see also: Birger Hjørland (2015). "Theories are knowledge organizing systems (KOS)". Knowledge Organization, 42(2), 113–128. "It is generally understood in KO [knowledge organization] that concepts are the units of KOSs [knowledge organization systems], but the theory-dependence of concepts brings theories to the forefront in analyzing concepts and KOSs. The study of theories should therefore be given a high priority within KO concerning the construction and evaluation of KOSs." ↩︎
The coordination of thoughts in a system of justifiable inferential norms reminds me of Moshman's developmental psychology of reasoning: David Moshman (2004). "From inference to reasoning: the construction of rationality". Thinking & Reasoning, 10(2), 221–239. ↩︎
Michael K. Bergman (2018). A Knowledge Representation Practionary: Guidelines Based on Charles Sanders Peirce. Cham: Springer. ↩︎
@Andy said:
I just noticed that Bergman also wrote the article on "Hierarchy" in the Encyclopedia of Knowledge Organization:
Since @ctietze's original post is about subsumption relations (a type of hierarchy)—@ctietze used the term abstraction from programming, but subsumption may be the better term—I would suggest that this article by Bergman is worth processing.
@Andy I guess my anti-academia ressentiment kicked in...
The problem I see with current academic approach to find is that it either geared towards developing material that can be used for machines (e.g. AI, specific software etc.).
I find it hard to get inspired by that material to create something for people.
It reminds me of learning first-order logic and inductive logic. It was nice training. But in practice, you just need a couple of syllogisms, and you're good to go.
I am a Zettler
@Sascha: That's reasonable. I think especially for you and @ctietze it must be hard to see the relevance since (if I'm not mistaken) you both reject any kind of formal note typology in a note system, or at least you don't teach it. Whereas I use a more detailed semantic schema in my note system, so semantic technology and its intellectual foundations is clearly relevant to my own system.
@ctietze: I found a paper that says something like your original post above: Yiyu Yao (2007), "Structured writing with granular computing strategies", in: Lin, T. Y. (ed.), Proceedings of the 2007 IEEE International Conference on Granular Computing (GrC 2007): San Jose, California, 2–4 November, 2007 (pp. 72–77). I found this paper because I noticed that it was cited in another paper (by the same author, Yao) that was cited in Bergman's "Hierarchy" article that I linked above.
Yao's paper frames the topic in terms of granular computing, which I had never heard of before, but it's not hard to see the similarity between "granularity" and "atomicity".
@Andy The diversity of things you bring up is staggering!
Thank you!
I skimmed the article: Since you recommended it, I had somewhat high expectations, but found I had a hard time keeping my good will up. I wonder if I'm missing something.
Did you take away anything in particular?
Article critique
The 'granular X' phrase is repeated so much in so many introductory sentences that it reads like marketing blurb. The tipping point came here:
That stood out as very sloppy writing, not what I expected around the point where from a hierarchical order follows more granular information in the parts.
Then later:
If X is considered a complex system, it's trivial to say that complex system stuff is applicable to X 🤔 Making plausible why one should think X is a complex system would be interesting! (I glossed over misapplication of the terms here already: "applicable to the process of writing", stressing the process in time, and then "considers an article to be a complex system", the result of that process, which is not a self-explanatory change of subjects)
It appears rather thrown-together to me. But maybe I'm expecting too much since this is only part of a 'proceedings' collection?
Author at Zettelkasten.de • https://christiantietze.de/
@ctietze said:
Ha! Sorry, I should have warned you that it's not a good paper. (And you found some especially bad passages in it.) Since it was written (probably hastily, as you said) for a conference on "granular computing", the author seems to assume that the reader is already a "granular computing" insider. I only mentioned it as an example of someone who wanted to compare computing structures and writing structures in a way that's like what you wrote above. For example, in the section "B. Writing process as constructing granular structures":
I wonder about his last paragraph:
Leaving aside some of the awkward writing here, he does seem to have a good point that more authors should be writing explicitly about how to use granular (i.e. atomic) structures in writing, while using insights from computer science. This paper did not actually give me such insights, but I agree with the author that such insights would be helpful. His last sentence seems to acknowledge that he didn't accomplish much in the paper, that the paper is only "a call" for more writing about this topic.
It is not that I am rejecting it. I just never saw such formalization convincingly increases the effectiveness or efficiency of a note-taking system, nor was I able to make it work, at least for me.
Of course, I have more rigid arguments against the benefit of such formalisations (not for all domains and fields!), but it just takes one good counter example to destroy my house of cards.
Perhaps, you want to present your system in a guest post?
I am a Zettler
@Sascha said:
Thank you for the invitation, but I don't know whether I want to put myself on such a high pedestal as this esteemed blog—probably not!
Fortunately, Joel Chan independently invented and teaches a similar system, which I consider to be validation that I am not the only person who has found such a system of note types to be useful. A simple version of it is in use at his open-notebook website Scaling Synthesis. And the documentation of a related extension that he wrote for Roam Research is informative: "Querying your discourse graph" and "Extending and personalizing your discourse graph". I haven't seen any publications from him with empirical evidence of his system's effectiveness, but I would not be surprised if such a publication will be forthcoming.
I believe any community member would be happy, and the whole of the internet, too.
I am a Zettler
This popped up on X today. I was wondering if there's fission happening here
I remember that I've already written something about analogies between notetaking and programming. Developing further this theory is one on the "task" in my list...
I put a copy of the original post even in this thread, for future reference.
I think that maybe not Zettelkasten itself, but "zettelkasting" practice of people brings something from program developing theory, also.
It's too early for me for theorize about, but when I create notes I feel the same forces that I feel when I design/develop.
The first thougths that come in my mind:
Also It hit me a phrase of Andy Matushak in his garden: "titles are like APIs". I agree with him. Good title for notes has the same importance of good interfaces in development. It represents the way used for make relationships with other notes.
I think that I'll develop this idea further in future.
Bottom-up developing - bottom-up notetaking (a part of TDD) is a very interesting analogy for me, need to develop. I notice that during notetaking and developing I follow the same approach.
@andang76 "Bottom-up writing" I'd rather put into a basket with functional programming paradigms, where you don't start with higher-level objects, but noodle your self up from small functions to composed functions.
(I do get the reference that TDD promotes this, but I'd rather leave the technique of 'testing' for something else. When I was looking for ways to implement test driven writing tools, LLMs were not a thing, but maybe you could now write a suite of assertions "my text clarifies that ..." and have a tool figure out if that's the case)
I believe the similarity on the practical level stems from the similarity of both software programs and Zettelkasten knowledge bases on a higher level of abstraction: both are complex dynamic systems.
As a consequence, one can borrow some of the practices from programming for similar tasks in Zettelkasting: refactoring a note, for example. What once looked like a cohesive function with a single responsibility now appears to be divisible, so you can extract parts as functions or objects. With the Zettelkasten, the same is true for notes. --- And spending more than a decade in both fields, I can attest that it's 90% gut feeling where and when to make cuts, and the effect after applying the change shows if it was good.
Author at Zettelkasten.de • https://christiantietze.de/
Yes, I forgot to mention refactoring. It's an important thing that I use in both.