I'll quote from the linked page regarding my conclusions:
------------>8----------
But in the end, I was never able to realize the promised benefits of Literate Programming. The typeset PDF was not easier to read than hypertext documentation generated by Haddock, and both were obviously worse than the very nice docs being created by the Python community with Sphinx.
So in mid 2012 (~3 years after starting the project) I removed all the literate annotations and styles, dropped the fancy build scripts, and released haskell-dbus 0.10 as standard Haskell.
------------>8----------
I'm sure an expert in LaTeX could do a better job with the formatting, and with the benefit of 10 additional years of experience there are some design decisions I would do differently in the code, but even so I think it was a reasonably effortful attempt.
I've never felt any urge to try Literate Programming again.
[0] https://john-millikin.com/software/anansi#history
[1] https://github.com/jmillikin/haskell-dbus/releases/download/...
——— <redacted> ———
Update: apparently HN doesn’t like some characters…
Anyway these are the characters: https://unicode.org/charts/nameslist/n_2700.html
- 2700 Black Safety Scissors
- 2701 Upper Blade Scissors
- 2702 Black Scissors
- 2703 Lower Blade Scissors
- 2704 White Scissors
Previously:
> There is a way to write a plain text file so that it looks the same (i.e. appears as plain text) whether it has the .txt extension when it's opened in a text editor and/or Web browser versus whether you rename it to have a browser-associated file extension like .htm or .html and then re-open it in a Web browser.
Why is this relevant? Because:
> Documents opened Web browsers are programmable.
From <https://news.ycombinator.com/item?id=35389974>
> If folks were really committed to improving the developer experience, then instead of what we do now [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html
That said, this approach only works for projects that themselves target the browser, since the loaded script would be unable to execute commands outside of the browser (without some kind of companion application which runs a web server locally).
The articles cover various aspects of literate programming, such as its history, benefits, challenges, tools and examples. They also explore some of the criticisms and misconceptions that surround the concept. Some of the articles are written by Donald Knuth, the creator of literate programming, and others are written by practitioners and researchers who have used or studied it.
I think this is a valuable resource for anyone who is interested in learning more about literate programming or who wants to give it a try. I’m curious to hear what other hackernews users think about literate programming and if they have any experience or advice to share. Do you think literate programming is a viable and useful way of writing code? Why or why not?