I've tried literate programming multiple times and not really succeeded in adopting it. The problem lies in the fact that programming is a constant switch between thinking about design and implementing it, and the latter provides more useful feedback since its at the business end of things. This is why programmers prefer documenting code rather than embedding it inside documentation.
What you really want is a solution that allows you to document your design to the extent that it clarifies your thought about implementation, then write some code which gives you results, then correct your design assumptions, and repeat while keeping the code and documentation in sync.
Assuming code and docs coexist in the same source repo, the keeping in sync part is the tough piece. What if the editing surface was based on content addressable objects, like a git repo? Names would be pointers to specific versions of the content, allowing for doc content and code content to be linked with each other's content hashes.
What you really want is a solution that allows you to document your design to the extent that it clarifies your thought about implementation, then write some code which gives you results, then correct your design assumptions, and repeat while keeping the code and documentation in sync.
Assuming code and docs coexist in the same source repo, the keeping in sync part is the tough piece. What if the editing surface was based on content addressable objects, like a git repo? Names would be pointers to specific versions of the content, allowing for doc content and code content to be linked with each other's content hashes.
