> Yeah, it can look a bit repetitive if the code is already clear, but the context of why a thing is being done is still valuable. In the modern era with LLM tools, I'm sure it could be even more powerful.
Is that because of literate programming, or is that because practicing literate programming made you focus more on writing high quality code and docs?
I'd argue it's the same thing. When doing literate programming, I started by first writing a description of what I was going to do and why. Then I wrote the implementation. When I finished, I went back and updated the description to match what I'd done. Maybe I'd get the idea to improve the approach and repeat this for a few cycles.
But the specifics of the flow aside, it's the mindset difference that makes it all feel special. The docs are the primary artifact. The code is secondary.
In an era of Copilot-style inline suggestions, taking the time to write a lengthy description effectively feeds the prompt to get a better output.
I tend to write doc-comments before the functions they document, because it helps me think more clearly about what I want to happen - and sometimes causes me to entirely re-think my approach and abandon the function entirely.
I can definitely see such a practice improving LLM output.
Meanwhile, there are programmers that think comments are a "code smell".
Is that because of literate programming, or is that because practicing literate programming made you focus more on writing high quality code and docs?