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

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

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

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
tools).

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

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” [http://db.tt/X8debml],
“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
practice.