Literate Programming and Leo

jko9 writes "First proposed almost 20 years ago by Donald Knuth, the idea of Literate Programming is basically that of making program documentation primary, and embedding code in the documentation, rather than vice versa. Despite some obvious advantages apparent to anyone who has struggled to understand a poorly documented program, literate programming never really caught on. That all could change, however, with the release of a new program called Leo, written by Edward K. Ream. Leo supports standard literate programming languages like noweb and CWEB, but with a crucial difference - Leo adds outlines. The effect is striking: overall organization of a program is always visible and explicit. Much of the narrative of the documentation gets placed in the outline, making documentation simpler, and allowing viewers to approach the code at various levels of detail. Screenshots and tutorials for Leo are here - if that site gets slashdotted, you can download the visual tutorials in .chm form or html form from Leo's Sourceforge site. Leo is an open source program written in Python. Any current practioners of Literate Programming techniques out there? People who have tried it and given it up? Can the addition of outlines to Literate Programming make it more powerful / popular?"

Comments

Re:COX

[unicron]

The Cox plan is not a T1, you newb. It's 1.5mbit down, 128 up. A T1 is 1.5mbit both ways. Wake up, ass.

Re:COX

[unicron]

So your condo is wired with fiber? Well, unless Cox has a CO inside your living room, I really don't think that matters.

thought for java geeks out there

[kisrael]

I'm not liking EJBs very much, and I think this post points to some of the reasons why...there's so much damn boiler plate code there, just to do the same simple tasks. (and making it worse, I have a general distrust of those fancy-shmansy editors that try to do all that bean stuff for you.) Approach someone else's code and you first have to figure out where to begin...naming conventions can help, but still.

EJBs (especially entity beans; session beans (especially stateless ones) are ok, though for 90% of uses regular java classes and static classes could do the same thing) seem to be the antiperl in some respects; it makes the easy jobs difficult and the difficult jobs impossible.