31–40 of 112 posts
It would be great if IDEs supported literate programming; the tangle/weave commands, simple as they are, create many possible points for navigation. An IDE would be ideal to go back and forth from the prose to the code.
I found this years ago: http://leoeditor.com/
This talked about writing code for humans then immediately jumped into some arcane mathematic scrawl like the stuff when Sephiroth casts supernova
This works well for people who are writers by nature (like Knuth who's always making edits and improvements to his books https://news.ycombinator.com/item?id=30149221). One problem though (and there are several) is that because this is so personal, nearly everyone who seriously tries LP ends up writing their own LP tool (including the author of this post!).
I have always felt a literate program is probably for many of us, a future deliverable on the hack we've implemented up front. Very very few people can start from the abstraction and get TO a literate outcome without a lot of false steps along the way. Or, as an alternative, the LOC of a literate program has to include the 100x cost of exploring how to carve it out of the block of mud we start from, including making…
Earlier quoted context omitted.
I think it's as good as it gets. The rough principal is there: You have one file, and you can derive the documentation and the program from it with different compilers. The idea of reading code like a book seems extremely flawed to me, and any attempts to create such languages either look like regular source code with slightly different syntax or are barely comprehensible (e.g. TeX)
Have you actually read TeX: The Book? It is far from “extremely flawed”.
Early C compilers, prior to prototypes, were rigid about the order of the various functions and includes, and that interfered with the exposition of the design. Literate programming was created by Knuth to address that.
The problems one will run into with literate programming: 1. Lack of tooling. 2. Refactoring becomes nontrivial 3. How one would write a program in literate style will vary widely from person to person. If you write your code in literate style, it may be easy for you to follow it years later and modify it, but it likely will not be the case for a coworker. If they have to modify the code, the cognitive load will not…
As someone experienced in the topic, What's the biggest hurdle when trying to refactor the code?
Are there any large (> 5 people teams) projects written with literate programming? Also are there any IDE plugins or error stack trace/debuggers for literate programming? I haven't really paid attention to literate programming in a long long time and I'm curious if the field has advanced. (Also I don't understand this: "A typical literate file produces many source files." Why? Why would you care about having multiple…
Syntax highlighting? Good luck! But possibly you could work around this, e.g. via custom highlighting syntax. Same with any auto-complete, contextual IDE help, etc. Refactoring was painful.
Also, the text absolutely destroys being able to scan and reason about the control flow quickly. Especially bad when a dev decides something needs "a lot of documentation" and writes a small novel.
Needless to say, it was truly awful.
My favorite literate program still has to be the book "Physically Based Rendering". An optimized, feature rich ray tracer in the form of a textbook. That said, I wouldn't personally want to try and collaborate on such a program with more than one other person. It would make for a great single-contributer OSS library though. Rubber duck debugging built right into the prose.
You can also find older, physical editions on EBay for $10-$15.
Earlier quoted context omitted.
I think it's as good as it gets. The rough principal is there: You have one file, and you can derive the documentation and the program from it with different compilers. The idea of reading code like a book seems extremely flawed to me, and any attempts to create such languages either look like regular source code with slightly different syntax or are barely comprehensible (e.g. TeX)
Have you actually read TeX: The Book? It is far from “extremely flawed”.
I think it is very hard to comprehend what one single part of a given algorithm does and it's imho almost impossible to get a good picture of how all these pieces fit together.
[1] https://texdoc.org/serve/tex.pdf/0 [2] https://mirror.las.iastate.edu/tex-archive/systems/knuth/dis...
I’d like to see a literate programming version of GitHub where the community standardizes around an eminently-readable Markdown-like syntax. srcweave [1] looks like a great start. [1]: https://github.com/justinmeiners/srcweave
See https://observablehq.com/@observablehq/a-taste-of-observable... as a quick overview.
To plug my own work, I have written https://observablehq.com/@mjbo/genre-map-explorer-for-spotif... in a literate style, and many of the Observable community are similar adherents to literate programming.