3 ms·
Literate programming can be done in any language. Here is an example in HTML: http://axiom-developer.org/axiom-website/litprog.html http://axiom-developer.org/a
by daly 15y ago
Literate programming can be done in any language. Here is an
example in HTML:
http://axiom-developer.org/axiom-website/litprog.html http://axiom-developer.org/axiom-website/litprog.html
In addition to the benefits mentioned there are at least 3
others I can site.
First, since you spend time explaining why you are writing
the code and your thoughts on the design and implementation
you naturally discover edge cases, missing cases, and bugs.
As a result, the quality of the code is higher.
Second, if you program in a team that does code reviews,
the team can see your approach to the solution and the
reasons. They can critique your work at a more profound
level. If the code review happens before accepting the
change commit, the quality of the code is higher.
Third, code lives. Sourceforge is a gravesite of hundreds
of thousands of programs that have died because the authors
are no longer maintaining the code. New users are confronted
with a source tree of tiny files which they are unable to
understand and therefore unable to modify and maintain.
I have the "hawaii test" criteria. If you can hire a new
developer, give them your program, send them on a 2 week,
all expense paid vacation to hawaii, and when they return
they can modify and maintain the program as well as the
original authors, then you have a fully literate program.
As for the question of debugging, I find that it is no
different. Generally the source of bugs are the same (e.g.
using copy/paste and failing to properly fix the copy).
Literate development, for me, takes on two different styles
depending on the language.
In a language that allows a read-eval-print loop, like lisp,
it is trivial to work in emacs with a command line in one
buffer and the literate sources in another buffer. You just
point at the changed code and evaluate it immediately in
the other buffer. It is very productive.
In a language like Java that is a pure compile environment
I create a makefile that extracts the code from the
literate document into the proper com.foo.baz.... source
tree, compiles the code, and runs the test regression suite.
This generally takes less than a minute or two for most
reasonably sized Java programs. So I make a small set of
changes, save the buffer, run 'make', and see if the tests
pass. For TDD programming I find this works very well.
My last large program was 60000 lines of Lisp in a latex
literate file. Tex'ing the file with all of the literate
documentation generated 6000 pages. The technology scales
quite well.
Learning literate programming is like learning lisp. You
keep wondering why anyone would program this way until you
suddenly "get it". Once that happens you wonder why anyone
could program any other way.
Tim Daly