
Programs to Read - danso
http://www-cs-faculty.stanford.edu/~uno/programs.html
======
danso
This page has obviously been around for awhile (or at least looks like it has
:))...but one thing I didn't notice until recently is that Knuth is apparently
still updating it with new programs. If you scroll to the bottom, there's at
least one program labeled as "August 2015"

------
dschiptsov
I am afraid that this is a wrong recommendation - too narrow, too esoteric,
too academic.

I would suggest to read Norvig's old Common Lisp code from his Paradigms Of
Artificial Intelligence Programming masterpiece (and the whole book, of
course).

AIMA and SICP are obviously good reads - the code is polished like fine poems.

Norvig's new Python courses on Udacity are also absolutely wonderful, but the
classic books are still the classic books.

And then arc.arc, of course!)

~~~
CmonDev
_> I am afraid that this is a wrong recommendation - too narrow, too esoteric,
too academic ... I would suggest to read ... Common Lisp code_

That is sure mainstream.

------
zyxley
I'm not asking this to be snide, but as somebody generally unfamiliar with the
literate programming concept - for practical purposes, what makes this
different from having well-encapsulated functions with thorough commenting?

For an example of what I mean, see underscore.js [1] and the prettyfied
version of the source [2].

[1]:
[https://github.com/jashkenas/underscore/blob/master/undersco...](https://github.com/jashkenas/underscore/blob/master/underscore.js)

[2]:
[http://underscorejs.org/docs/underscore.html](http://underscorejs.org/docs/underscore.html)

~~~
kencausey
One of the primary differences is that the document can be structured, i.e.
ordered, to benefit readability and not for the needs of the software. At the
point that source code is needed for tools the literate version can in one
step be used to generate it. Even multiple files in a hierarchical directory
structure can be generated from a single literate software document.

~~~
jerf
I like to point out that when Literate Programming was first proposed,
software was a great deal less malleable than it is now. LP vs. the rigid
structures of the time is one thing, LP vs. the malleable structures of today
is quite another. Cast back in time I might prefer LP in the past, but today,
it's an awful lot of complexity and a huge layer to add on top of our systems
for what is of significantly less _relative_ utility. Very little stops you
from having more narratively-coherent code today, in existing systems; the
problem is more human than tool now.

------
ilurk
TIL about cweb. [1]

> CWEB is a version of WEB for documenting C, C++, and Java programs. WEB was
> adapted to C by Silvio Levy in 1987, and since then both Knuth and Levy have
> revised and enhanced the system in many ways, notably to support C++ and
> ANSI C. Thus CWEB combines TeX with today's most widely used professional
> programming languages.

> If you are in the software industry and do not use CWEB but your competitors
> do, your competitors will soon overtake you---and you'll miss out on a lot
> of fun besides.

I guess it never took off due to the "I'll do it latter when I have time
mantra". Documenting and testing are always seen as low priority.

Trying to convert maxcliques.w but it rightfully warns about missing
gb_types.w

Is there a zip file with all programs and dependencies?

texlive-binaries ctangle also seems to be losing some formatting.

[1] [http://www-cs-faculty.stanford.edu/~uno/cweb.html](http://www-cs-
faculty.stanford.edu/~uno/cweb.html)

~~~
angersock
Nobody's business was ever ruined because of bad documentation, sadly.

Literate programming is an interesting idea from academia, but in the
engineering environment of most startups it's a waste of time. Our program
sources are annoying byproducts of a business, not something of value unto
themselves.

~~~
jlg23
> Nobody's business was ever ruined because of bad documentation, sadly.

I've seen quite a few startups fail because they had a smart, but completely
undocumented code base. Then the smart programmers leave and who is left
cannot handle the code and new hires take too long to get into it. Then
funding runs out and the apparent lack of progress ensures that nobody wants
to put more money into the company.

> Literate programming is an interesting idea from academia, but in the
> engineering environment of most startups it's a waste of time.

Amazingly, we're actually getting back to something that resembles literate
programming - via TDD. Instead of asking for a proper spec, we now ask for
test definitions that the code must pass. Those can even be written in
something that is pretty close to natural language (cucumber etc) so that
management can write them. Then we spend time to make the test framework
understand all those pseudo-natural-language test definitions and then we
finally write the code. Is that really faster? Or are we just missing the
tools that would allow us to tie a natural language specification to code?

~~~
copperx
> pretty close to natural language (cucumber etc) so that management can write
> them

This sounds so familiar ...

~~~
douche
What a jokester! Management doing work?

Then the engineers get to program in a less-powerful, more cumbersome
language.

------
Jun8
For those who may be new to Literate Programming, here's information on how to
process CWEB files:
[http://www.readytext.co.uk/?p=2475](http://www.readytext.co.uk/?p=2475)

------
justin66
CWEB: the second most effective way to keep people from reading your code,
after simply writing it in Lisp.

~~~
draven
Use scribble/lp2 [0] to do both !

[0] [http://docs.racket-lang.org/scribble/lp.html](http://docs.racket-
lang.org/scribble/lp.html)

------
lekanwang
A lecturer at Stanford CS (Keith Schwarz) also has a good collection of
various implementations of interesting algorithms:
[http://www.keithschwarz.com/interesting/](http://www.keithschwarz.com/interesting/)

------
douche
I'm not sure I see the point...

You could make things much more readable by just using decent formatting and
descriptive variable names. I know, it's decorated C code, and academic C code
at that, but damn, some of that stuff is a mess to try to read.

Maybe I've been in C#/Java/Python/JS land for too long, but
javadoc/xmldoc/docstring documentation is a lot more readable. If you really
want to, you can dump in markup, pictures, non-ASCII characters, etc into the
html-based documentation.

The more I look at it, this stuff must be a monstrosity to try to actually
write. I can't see it being at all attractive, unless you were doing well-
defined, algorithmic code. Or you could write it in normal C and package it as
a library that people might actually use.

~~~
boxy310
The author is Donald Knuth, in case you didn't catch that. Since most of these
are dated from the 90's, you should probably be comparing verbosity to COBOL
or PASCAL and keeping in mind this was from before the ubiquity of Linux or
Python, and long before Java, Javascript, or C#.

~~~
douche
Most of them are dated from the 2000s.

It's hard to miss that it's on Knuth's website. Just because it's published by
one of the gods of computer science doesn't mean that it is code in a style
that anyone should be encouraged to emulate.

------
amelius
Hmm, why haven't the processed files been posted as well?

~~~
prestonbriggs
Knuth is posting source and you want the assembly?

~~~
gohrt
No, parent is asking for the rendered document. Analogy: The source is like
HTML; parent is asking for the rendered document as you would view it in a web
browser.

------
CuttlefishXXX
"Change files" are refered to quite a lot. What does that mean?

------
mrcactu5
the algorithms look good but the code seems a bit arcane

