23 Matching Annotations
  1. Jul 2024
    1. We decided that we would like to see better documented code included within web pages for convenient browsing. The motivation behind this peculiar aim is to be able to include high quality documentation alongside working code, hopefully making it easier for programmers to produce more maintainable, readable programs.
  2. Jun 2024
  3. Oct 2023
  4. Jul 2023
    1. Colaroid’s unique ap-proach to literate programming is to bring together the rich textediting affordances of notebooks together with automated creationof contextualized code snippets showing code differences, and closeintegration of the literate document into an IDE where code can betinkered with.

      This misses the point of LP—the true "fundamental theorem of LP" is basically that the compiler should be made to accept the preferred form.

    Tags

    Annotators

  5. May 2023
    1. I think that TANGLE-style reordering is a lot less important with modern programming languages: they don't do one-pass compilation and so can deal with forward references. Note that most of the cross-references in Knuth's program could be replaced with function calls or constant names
  6. Jan 2023
    1. Literate programming worked beautifully until wegot to a stage where we wanted to refactor theprogram. The program structure was easy tochange, but it implied a radical change to thestructure of the book. There was no way we couldspend a great deal of time on restructuring thebook so we ended up with writing appendices andappendices to appendices that explained what wehad done. The final book became unreadable andonly fit for the dustbin.The lesson was that the textbook metaphor is notapplicable to program development. A textbook iswritten on a stable and well known subject whilea program is under constant evolution. Weabandoned literate programming as being toorigid for practical programming. Even if we got itright the first time, it would have failed in thesubsequent maintenance phases of the program’slife cycle.

    Tags

    Annotators

  7. Dec 2022
  8. Jul 2022
  9. Jun 2022
  10. May 2022
    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, with their 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.

  11. 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.

  12. Mar 2022
  13. 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"?

    Tags

    Annotators

  14. Oct 2021
    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.

  15. Mar 2021
  16. May 2020