11 Matching Annotations
  1. Last 7 days
    1. This column will continue only if I hear from people who use literate-programming systems that they have not designed themselves. and it did not continue.
    1. Knuth recommended getting familiar with the program by picking up one particular part and "navigating" the program to study just that part. (See https://youtu.be/D1jhVMx5lLo?t=4103 at 1:08:25, transcribed a bit at https://shreevatsa.net/tex/program/videos/s04/) He seems to find using the index (at the back of the book, and on each two-page spread in the book) to be a really convenient way of "navigate" the program (and indeed randomly jumping through code, as you said), and he thinks that one of the convenient things about the "web" format is that you can explore it the way you want. This is really strange (to us) as the affordances we're used to from IDEs / code browsers etc are really not there

      I can't help but think that currentgen programmers are misunderstanding Knuth and anachronizing him, being a product of the current programming regime where most never lived in a world without structured programming, for example, when we hear "literate programming", we attempt to understand it by building off our conception of current programming practices and try to work out what Knuth could mean given widespread modern affordances as a precondition, when really Knuth is just advocating for something that approximates (with ink and paper) currentgen tooling, and is therefore in fact more primitive than our reference point which we are trying to understand as being capable of being improved upon, but Knuth's LP is an improvement nonetheless of something even more primitive further still.

    1. in other words, there would be no "weave" step

      Well, there could still be a weave step—same as there is like with triple scripts (to go from compilation form back to the original modules) or with Markdown, which should be readable both as plain text and in rendered form.

  2. Apr 2022
    1. The SE server is also responsible for building ebooks when they get released or updated. This is done using our ebook production command line toolset.

      It would be great if these tools were also authored to be a book—a comprehensive, machine-executable runbook.

  3. Mar 2022
    1. Literate programs allow you to answer these questions naturally.

      And in environments without tangle and weave, you can get pretty far by just making sure to write code top-down.

  4. Feb 2022
    1. the guide shall be written in such a way that all we have to do is produce the guide itself and then a computer can do the heavy lifting—where we might otherwise expect a separate, possibly GUI-driven, "app" to be created for the end user to interact with, we accomplish the same effect by making the guide very detailed—in part also an attempt to evoke the style and quality of old equipment operation and repair manuals that used to be available, when such manuals could be expected to include e.g. full schematics. If done correctly, this should be sufficient for the guide itself to be interpretable by a machine.

      "comprehensive codebook"?



  5. Oct 2021
    1. In my method, program segments are embedded in the midst of a word processor document--like raisins in cake--so that the emphasis is on the explanation rather than the code.
    1. Any language or system that does not allow full flowing and arbitrarily long comments is seriously behind the times. That we use escape characters to “escape” from code to comment is backwards. Ideally, comment should be the default, with a way to signal the occasional lines of code.

      Sounds like literate programming.

  6. Mar 2021
    1. There are currently three implementations of the ActivePapers concept: the Python edition, the JVM edition, and the Pharo edition

      There is only one reasonable approach, and it's not even mentioned as an option here: the browser edition. (I.e., written to target the ubiquitous WHATWG/W3C hypertext system.)

  7. May 2020