@marick @khinsen @liberty

One aspect of literate programming that I value is that it is linear, so perhaps it could in principle be corelated with the "passing time".

But my issue is that program development is non-linear: I implement some functionality, but then it turns out that I need to revisit it.

And I'm not sure how to signal that to the reader. In normal life the most convenient way is just to revisit file and make a change.

But im case of a literate program, I'd either need to have some means to modify/override previous definitions (which can be confusing to the reader, but is honest in showing my thinking process), or I can go back and fix the narrative, which makes it denser and also somewhat dishonest.

On the other hand, it may also be a matter of the question whether my goal is to show my thinking process with high fidelity, or to explain the program in a way that is optimal for the reader (I think that the latter approach is better, but also much harder).

Perhaps it would be ideal if the program could be written in an incremental manner, but I'm not sure if that's even possible.

One thing that I think is good in my approach is that, as I write subsequent parts, I develop executable tests, so I can see if the parts of the book written so far are correct, and pieces of code that are scattered around various places are taken together to a single file. But I'm still not sure if there's going to be anyone willing to read what I wrote.

@khinsen @PaniczGodek @liberty I tend to start documentation of my software systems with a diagram, because models are well communicated visually. Unfortunately it is harder to write and update diagrams than writing text and naming things. Most tools are inconvenient and limited to their design choices. Pen and paper works best.

@khinsen this looks great! @liberty