Literary programming

    In less than a month I learned about literary programming, but
    the concept itself made a lasting impression on me, made me
    rethink some things and reduce the ardor with maximalism
    in some judgments. On the technical side of literary
    programming (I call it literary rather than literate; it
    seems to me closer in meaning to the original title) I saw a couple of
    wonderful articles in RuNet, but I want to talk about
    its emotional side, I hope this will give you motivation to dig
    deeper. Emotional words would have sounded from my lips a
    little ... fanboyly, so I’ll leave them for later, but now
    I suggest you read a few quotes from the creator of the methodology, Donald

    I did the translation with the help of Google Translate, and this is my
    first published translation - I'll ask you to kick only in the case.

    Fragments from an article in Literate Programming, 1983:

    I believe that the time has come for a much better documentation of the
    programs, and that we can achieve this by making the programs

    Let's change our traditional attitude towards building programs:
    instead of imagining that our main task is to tell the
    computer what to do, let's focus on explaining to the person
    what we want the computer to do.

    A practitioner of literary programming can be regarded as an
    essayist whose main concern is exposition and the perfection of
    style. Such an author, with a dictionary in his hand, carefully selects the names of the
    variables and explains why each of them is needed.

    It is worth thinking seriously in the above quote and not skipping over
    as something obvious. A lot of meaning is packed into the word exposition , and
    its understanding is essential for revealing the idea of ​​literary
    programming. I give the definition from Wikipedia.

    An exposition in literary criticism is a part of a work preceding the
    beginning of the development of units of the structure of the work, in particular, a part of the
    work that precedes the beginning of the plot. The exposition follows the
    arrangement of the actors, circumstances arise, the
    reasons are shown that “trigger” the plot conflict. The exposition can
    follow both before the tie and after.

    Exposure in drugs is one of the main ideas; the point is that the
    author must explain to the reader of the literary program where
    any piece of code came from and why it is where it is.

    He or she seeks a program that is understandable because her ideas
    have been presented in an order that is best for human
    understanding, using a mixture of formal and informal methods that
    reinforce each other.

    We understand a complex system, understanding how its simple parts are arranged, and
    understanding the simple relationships between these parts and their closest
    neighbors. If we express a program as a network of ideas, we can
    emphasize its structural properties in a natural and satisfactory

    This is a word about why many of the tools for drugs have
    the word web [web] in their name .

    I dare to suggest that such advances in documentation are possible due to the
    experience that I gained over the past few years during
    intensive software development (here Knuth talks about
    developing TeX and METAFONT). Taking advantage of several ideas that have
    existed for a long time, and systematically applying them in a slightly
    new way, I came across a method of creating programs that
    excited me extremely .

    In fact, my enthusiasm is so great that I must warn the
    reader to perceive a lot of what I will say, like the delirium of a fanatic
    who thinks he has just gained
    enlightenment. Programming is a very personal activity,
    therefore, I cannot be sure that what worked with me will
    work with everyone. However, this new approach has fundamentally influenced
    my own style, and my excitement has not subsided to this day - for more than
    two years now. I like this new methodology so much that it’s hard
    not to go back to every
    program I ever wrote and to convert it into a “literary” one.

    I cannot resist the desire to work on
    programming tasks that I usually assign to student
    research assistants ; and why? Because it seems to me that at last I can
    write programs the way they should be written. My programs do not
    only explained better than ever before; they are better as programs
    because the new methodology makes me do my job better.

    A small excerpt from an interview with Donald Knut, 20 years later:

    - One of your few projects that did not reach a wide
    community of programmers is literary programming. What are
    your thoughts on why literary programming has not taken root? And
    is there anything you would do differently in retrospect
    regarding literary programming?

    - Literary programming is a very personal thing. I think it's
    awesome, but maybe it's because I'm a very strange
    person. He has tens of thousands of fans, but not millions.

    Judging from my experience, programs created using literary
    programming turned out to be much better than programs
    developed in a more traditional way. But ordinary programs still
    were good enough, so the traditional methods remain with us -
    they are understood by the vast community of programmers, and most people
    have no particular need to change anything; just as I am not motivated to learn
    Esperanto, even knowing that it may be preferable to English,
    German or Russian.

    John Bentley probably dotted the i when he was asked “why did
    literary programming not conquer the world?” He said that only a
    small percentage of all people are good at programming and a small
    percentage are good at writing; and you ask me that all people
    be in these two categories at once.

    As for me, literary programming is the most important thing
    which came out of the TeX project. It not only allowed me to
    write and maintain programs faster and more reliable than ever, it was
    one of the greatest sources of joy since the 1980s, and at times
    it was impossible to do without it. Some of my main programs,
    such as the MMIX meta-simulator, could not be written using
    any other methodology I have ever heard of. They were
    just too complicated for my limited brain; without
    literary programming, such an enterprise would simply fail

    If people discover good ways to use newfangled
    multithreaded machines, I expect the discovery to come from people who
    everyday use literary programming. Literary
    programming is what you need to rise above the next
    level of achievement. But I do not believe in forcibly accepting ideas. If
    literary programming is not your style, please forget about it and
    do what you like. If nobody but me likes it,
    let him die.

    From the positive: I was pleasantly surprised to discover that the rules of CWEB
    ( literary programming system for C ) are already
    standard in pre-installed programs, such as Makefile, in
    modern Linux.

    As for me - I think that literary programming is very, very
    much lacking in open source projects and especially in teaching
    programming (it is not used formally with the appropriate

    Last year I watched very closely the life of the community of
    lisper-koskusturistov and absorbed all the information available on the network on
    this topic: the planet of blogs, twitter, 3 books published today. After a
    fairly tight “immersion” in this topic, I had a very
    vague suspicion about the approach to learning the Clojure language and its
    attendant infrastructure. Then I found out about PL and a vague
    suspicion cleared up. Judge for yourself. There are three books about
    Clojure and their contents intersect very much,
    approximately it can be described as 100,500
    recipes for loosely related to each other rake placement provided by the language of this
    particular version. Reading all three books will not make you
    professional. You can read a thousand such books -
    you do not become a master . All 3 books abut against an impenetrable wall; you know
    that behind the wall lies a treasure, simple and concrete; but you can’t
    get to it in any way through the thorns of disparate and unclear
    outlines. Such technical literature is the essence of clip
    thinking: it’s as if I’m fed a tightly brewed porridge from
    nutritious and damn useful pieces, but I can never
    to get enough, because they feed me secondary, leaving the essence

    Clojure, like all Lisp, is essentially an extremely simple
    construct. Someone said "source is the best documentation"; for the
    family of these languages, this is true. In fact, that part of the language that
    is directly used by the user is described on
    Clojure itself in a single core.clj file about 5 thousand lines in size. This
    code is transparent as a baby’s tear with comments from which
    fairly simple, but high-quality documentation is generated. Reading
    this file over a cup of tea will be the beginning of that very journey beyond the
    wall of clip-art to the very essence of the technology used. But further
    promotion turns out to be much more complicated - the next one will be
    Java sources, which describe the compiler, transactional memory,
    links, agents, and persistent data structures. And not a single
    comment - there the devil himself will break his leg. And after all, the thing is not at all
    complicated, but those who really thoroughly or at least roughly
    know the device of all this technology to its very foundations are orders of magnitude
    less than those who have studied it before this impassable wall.

    Another thing TeX - the glorious creation of the great master. If you want to become a
    real technician, you read from standard to standard the manual
    described in the TeXbook. I decided to become a burnt specialist - again you study
    from cover to cover, the TeX The Program book, in which all 20,000 lines of
    the TeX program (TeX is written in Pascal, damn me!) are described in
    simple understandable human language - this is a literary work, a
    detailed description of the program from a bird's-eye view down to the
    smallest detail . All. Two books. Alpha and Omega. The technology is described
    from bottom to top and from all sides - no one will say more. To
    fully experience the methodology, I highly recommend looking at Knut’s three great literary programs, “TeX The Program” [],
    “METAFONT The Program” and “MMIXware”.

    Literary programming is not just another approach to
    documentation. It is much deeper - it is a path connecting the hearts
    program and programmer. And this path will remain unfulfilled
    until literary programming is put into

    Also popular now: