Hacker News Reader

Comment by WillAdams | Hacker News Reader

Why not just put forth/use Literate Programming?

https://www-cs-faculty.stanford.edu/~knuth/lp.html

I've been working on a personal project for what I call "semiliterate programming" ;) because I think "Write a book about your code that happens to contain all of your code" is a bridge too far for nearly everyone.

So, I'm trying to find the place between Doxygen and full-blown literate programming. Encouraging disjoint prose documentation rather than parameter-by-parameter docs or chapter-by-chapter docs.

Doxygen Markdown Support made my system largely unnecessary. But, I still use mine because it has real-time preview, is based on https://casual-effects.com/markdeep/, and I personally don't care for classic Doxygen style documentation.

Meanwhile, this article sounds like it's about literate programming stuff. But, it's actually about using code-oriented tools to write documentation.

I'm finding that future-self really appreciates the effort past-self made to document things in book form:

https://github.com/WillAdams/gcodepreview/blob/main/gcodepre...

and

https://github.com/WillAdams/gcodepreview/blob/main/gcodepre...

for my current project.

Moreover, it seems to me that there would be a great deal of synergy in using Literate Programming techniques when:

>using code-oriented tools to write documentation.

Literate programming only works for small scripts and narrative documentation, not for e.g. API documentation.

OIC.

I guess that the books at:

https://www.goodreads.com/review/list/21394355-william-adams...

which include a typesetting system, a font design language, a 3D renderer, and an MP3 implementation qualify as "small scripts"? What is the threshold for such? TeX.web outputs some 20,619 lines of Pascal code for conversion to C and compiling.

"Doesn't work" does not mean that you can't write such books/programs/documentation. It means nobody (yes, yes, exceptions ...) can maintain such code. Look at Jupyter Notebooks - the most used literate programming environment nowadays - and their usual content. The main problem of documentation isn't solved by literate programming: how can you make sure that any relevant documentation has been updated, so that the docs are still in sync with the code.

I find that having the documentation in the same file and interactive with, and having the ability to include formulae and diagrams helps immeasurably in ensuring that the documentation is updated as the code changes.

This sounds logical, yet I have never seen that in my own code, the code of colleagues at work or other code. If the documentation is not somehow automatically tested against changes in the code, the documentation in the same file is almost always worse (as in "more wrong") than adding the changes in another document. I don't know why it's easier to remember or for others to check for updates in "special" files.

not true:

"This book describes pbrt, a physically based rendering system based on the ray-tracing algorithm." ( https://www.pbr-book.org/3ed-2018/Introduction )

and:

"This book (including the chapter you’re reading now) is a long literate program." ( https://www.pbr-book.org/3ed-2018/Introduction/Literate_Prog... )

And now imagine maintaining the code of PBR, and with more than 5 people working on it at the same time. Literate programming is great for reading, although I prefer having "real code" (which can normally be extracted, that's not a problem) to read too.

Btw. there is a newer - 2023 - edition available now: https://www.pbr-book.org/4ed/contents

I'm not saying it is for everyone, or for every project. My point was that "Literate programming only works for small scripts and narrative documentation" is far too wide-sweeping of a statement. There are plenty of non-trivial examples of its use, and it obviously "works" for some people.

It certainly does, but these "some" really are exceptions. Just try it for yourself, edit PBR and compare the experience to "just" editing the source code of PBR (yes, of course, not being used to something doesn't help). To be honest, I haven't looked at PBR for more than a decade so maybe I would succeed nowadays, but I doubt that.

I guess realising that literate programming is literally [sorry] writing a programming book should be enough of an argument to know that it isn't suitable for most people. And no, a white-paper is not a "programming book" suitable for most people to read ;)

There is far more to the actual software of pbrt then what is described in the book and the book is huge. All the mechanics of the architecture are really something you can only find out by looking at the actual C++ files.

https://www.pbr-book.org/

>A method known as literate programming combines human-readable documentation and source code into a single reference that is specifically designed to aid comprehension.

Where are these C++ files which are not included in the text?

Where are these C++ files which are not included in the text?

https://github.com/mmp/pbrt-v2

https://github.com/mmp/pbrt-v3

https://github.com/mmp/pbrt-v4

Have you read these books and modified the source to pbrt? The books contain small fragments of source code and aren't close to a full program.

Interesting.

I guess that including those lines would have been problematic in terms of book length/page count?

Reply on news.ycombinator.com