Re: [ba-ohs-talk] Leo Literate Programming
Oh, yeah. This could be *big*. Maybe even BIG. (01)
Two major points:
* Python depends on indentation to define nesting. But indentation
can be hard to keep consistent in a text file, especially when you
move things around. (02)
An outline-based editor is perfect for Python, because it adds
regularity. And since the braces which Java uses to enforce
meaning become superfluous, Python begins to be appealing.
(Although automatic data conversions can be a problem. They
make it easier to code, but harder to ensure correct behavior.) (03)
* Personally, I've never had much use for the "header is different
from the body" style of outlining. But when the header is a
readable comment, I might relax that position. (04)
Personally, I would still rather see this style, which is reflective
of the way Augment was implemented:
body of header (if any)
body of subheader (05)
where the header is just the first line of the entry. That makes it
possible to put in a multi-line comment, for example, where the first
line captures the essence, and subsequent lines expand on it.
(I think that style is better whenever multi-line comments are the
norm, as in Java's API comments.) (06)
The Leo implementation (forced by a lack of a good tree widget,
as much as anything) implements this, instead:
+ header (click here to see body of header)
+ subheader (click here to see body of subheader) (07)
That's the old outlining standard. It was implementations like that
which killed outlining in the first place. By the time a really good
implementation, people interested in outlining didn't even want to
Also, I note that their concept of "outlining" is rather different from
what I would have envisioned. In their sample definition, for example,
there are references to two sections that have literate headings, and
those show in the "outline". Then there is an if statement, with a then
and else clause. The then clause contains a statement or two, and
then a reference to another section. (09)
What shows up in the "outline" is the definition and the 3 references
to other sections. The if and else clauses don't show up in the outline
at all. (010)
They might be able to convince me otherwise, but to my mind this is
a rather strange way to think of an "outline" for the code. Reading
the outline derived from that structure would really not give me an
inkling of what is going on. (011)
So I see room for improvement in the implementation. But the concept
is awesome, and it could make a difference. Python might even become
a new favorite -- as long as every then and else clause got a definition,
so the the derived outline would reflect the structure of the code. (012)
Jack Park wrote: (013)
> I "blogged" this at my NexistWiki weblog.
> I am of the opinion that this is a very important project, one worth
> looking at carefully.
> and the project's home page (worth visiting!)
> · Leo is a programmer's editor and a flexible browser for projects,
> programs, classes or data. Leo clarifies design, coding, debugging, testing
> and maintenance.
> · Leo is an outlining editor. Outlines clarify the big picture while
> providing unlimited space for details.
> · Leo is a · literate programming tool, compatible with
> · noweb and · CWEB. Leo enhances any text-based programming
> language, from assembly language and C to Java, Python and XML.
> · Leo is also a data organizer. A single Leo outline can generate
> complex data spanning many different files. Leo has been used to manage web
> · Leo is a project manager. Leo provides multiple views of a project
> within a single outline. Leo naturally represents tasks that remain
> · Leo is fully scriptable using · Python and saves its files in · XML
> · Leo is portable. Leo.py is 100% pure Python and will run on any
> platform supporting · Python and · Tk/tcl, including Windows, Linux
> and MacOS X. Leo.exe runs on any Windows platform.
> · Leo is · Open Software, distributed under the · Python
> What's extremely interesting to me is that Leo looks like a really powerful
> tool, one worth looking at in terms of components in an OHS.
> XML Topic Maps: Creating and Using Topic Maps for the Web.
> Addison-Wesley, ISBN 0-201-74960-2.
> http://www.nexist.org/wiki/User0Blog (014)