literate programming

A good idea for many projects, no doubt. But I wonder if the dislocations of
the document and of reading that inhere in the code-centered program have
been important in new approaches to art associated with coding? In other
words, attempts to create 'literate programming' unlike the definition of
'literate programming' below have been fruitful.

But this has been at the cost of intelligability (which is often true in
poetry anyway). Not so bad a cost for projects in art, but costly in
engineering, definitely.

In a certain sense, much digital poetry seeks to unite document and
programming. Usually on the level of interface, though if the source is
available and there's writing about the source, that's deeper. It would be
great to be able to further unite document and programming in the ways
enabled by 'literate programming'. The document would be readable in the
programming environment. And of course also executable in or from that
environment.

The documentation should be amenable to not just text but multimedia.

ja

> "A traditional computer program consists of a text file containing program
> code. Scattered in amongst the program code are comments which
> describe the
> various parts of the code.
>
> In literate programming the emphasis is reversed. Instead of writing code
> containing documentation, the literate programmer writes documentation
> containing code. No longer does the English commentary injected into a
> program have to be hidden in comment delimiters at the top of the file, or
> under procedure headings, or at the end of lines. Instead, it is wrenched
> into the daylight and made the main focus. The "program" then becomes
> primarily a document directed at humans, with the code being
> herded between
> "code delimiters" from where it can be extracted and shuffled out sideways
> to the language system by literate programming tools.
>
> The effect of this simple shift of emphasis can be so profound as
> to change
> one's whole approach to programming. Under the literate programming
> paradigm, the central activity of programming becomes that of conveying
> meaning to other intelligent beings rather than merely convincing the
> computer to behave in a particular way. It is the difference between
> performing and exposing a magic trick."
>
> from http://www.literateprogramming.com/

On 28 Feb 2004, at 09:39, Jim Andrews wrote:

> A good idea for many projects, no doubt. But I wonder if the
> dislocations of
> the document and of reading that inhere in the code-centered program
> have
> been important in new approaches to art associated with coding? In
> other
> words, attempts to create 'literate programming' unlike the definition
> of
> 'literate programming' below have been fruitful.

I love the idea of literate programming (If I had the cash I'd buy
"Computers and Typesetting" tomorow) but I do wonder how appropriate it
is for real-world software design, especially rapid development and
personal projects. That said, I no longer believe in self-documenting
code having grown sick of AppleScript after recently using it for a
large-scale, real-world project. And I am looking for a good
pedagogical language, so maybe I'll try LP after all.

Languages like Lisp and Python allow you to embed documentation strings
in the code and these remain accessible at runtime, so you can read a
function's documentation as you write, compile and test the code.

For multimedia, you should be able to add SVG docstrings or just
arbitrary href docstrings. :-)

- Rob.

After researching it, I'm now doing my current project in Literate
Programming style, using noweb.

The advantages (for me) are:
- It helps me think about what I'm doing. I'm no computer scientist so
anything that makes hacking up algorithms easier is good.
- It should help me come back to the code to work on it later. This is
planned as a long-term project.
- It makes the program presentable for others to read and understand,
unlike, say, AARON.

So thanks for the link.

- Rob.