On Sep 3, 12:40 am, "Edward K. Ream" <[email protected]> wrote: > Inspired by Terry's recent post, I'm wondering how many of you can > tell the story of what you were doing and thinking when you first > "got" what Leo was all about.
My own story is different, since it started before Leo ever existed :-) The first part of the following is adapted from the start of Leo's History chapter, http://webpages.charter.net/edreamleo/history.html The second part is new. Beginnings Leo grew out of my efforts to use Donald Knuth’s “CWEB system of Structured documentation.” I had known of literate programming since the mid 1980’s, but I never understood how to make it work for me. Knuth's huge TeX system is presented in as a literate program in the TeXBook: http://www.amazon.com/TeXbook-Donald-E-Knuth/dp/0201134489 This book contains thousands of sections, arranged mostly in "stream- of-consciousness" order. In hindsight, I see now that the major problem was that there was no way for me to keep track of all these "sections". Knuth used various devices to try to make sense of this, including cross references, indices and literary-style introductions, summaries and transitions between sections. But I knew that I was not really understanding the program. In November 1995 I started thinking about literate programming in earnest. Over the holidays I mused about making literate programs more understandable. In January 1996 the fog of confusion suddenly cleared. I summarized my thinking with the phrase, web are outlines in disguise. I suspect I was thinking something like this: most sections in Knuth's program are called from only one other section. If the called section is represented as a child of the calling section, much of the essential structure of the program will be made visible. Naturally, the same remarks apply to functions, methods and even subclasses. I use the term "helper" to mean a function that is called from a small number of calling functions. Most helpers, in fact, help only one caller. So the natural place to place a helper in an outline is as the child of the function it helps. Again, this is perfectly clear in hindsight, but at the time many details remained obscure. Breakthrough March 5, 1996, is the most important date in Leo’s history. While returning from a day of skiing, I discussed my thoughts with Rebecca. During that conversation I realized that I could use the MORE outliner as a prototype for a “literate outliner.” I immediately started work on my first literate outline. It quickly became apparent that outlines work. I could immediately see that placing "helper" sections as child nodes of the section they helped removed all the confusion about the overall structure of literate program. The first "outline-oriented" program I wrote was a bootstrap: I hacked a translator called M2C so I could use MORE to write real code. I would write code in MORE, copy the text to the clipboard in MORE format, then run M2C, which would tangle the outline into C code. This process was useful, if clumsy. I called the language used in the outline SWEB, for simplified CWEB. Much later Leo started supporting the noweb language. The @others directive dates from the very first hour of using MORE as a prototype for a literate outliner. I realized that there was no particular need to give names to every chunk of code: the @others directive allowed me to access nodes without caring what their names were. Two later Ahas Back in 1996 I was still using C (not C++) almost exclusively. It seems like the dark ages. Python existed, but I didn't know about it. The internet existed, but I didn't have access to it. So I was cut off from the world of development in a way that is hard to imagine today. There were at least two more Aha's that shaped my view of Leo, but I don't have clear recollections about how they came to be. These realization likely happened more slowly, not in one Aha moment. The first Aha is that browsers do not, and **can not**, know how to organize my programs. The reason is clear: I don't know myself! That is, the proper organization of my code depends on what I want to do with it at the moment. For example, when I'm fixing a but, the proper organization is one that ignores all nodes except those relating to the bug. So there is no single one "right" organization of programs (or any other complex data). I had always been vaguely dissatisfied with class browsers. Even the SmallTalk browser, which in some ways is pretty cool, did not help me **in any way** to understand any organization except the "official" organization. Browsers did not then, nor do they have today, any memory of the nodes (or other organizations) that I like to create in Leo. Far from remembering my task-oriented organizations, most browsers do not even remember the part of the class hierarchy that I last visited! Class browsers suffer from Alzheimer's disease :-) It was an incredible piece of luck that I started with MORE as the prototype of Leo. MORE *does* have a memory, because MORE has clones. Leo's clones work *exactly* like MORE clones. So the Aha is this: clones create permanent views of data that can be remembered. The second aha took even longer to develop. Once Leo became an independent program, it was possible to write scripts that would access the nodes **in the outline containing the script**. The first versions of Leo were written in C, and then Borland C++, and I don't remember what kind of scripting features Leo had then. But in late 2001 Leo was born again as a Python program. It was natural to define the current node of an outline, and to provide getters and setters for that node. It took *years* of using the Python version of Leo before it became clear that one of Leo's biggest strengths is this: Leo has a rich DOM (Document Object Model). Other editors don't remember anything because **there is nothing except files to remember**. At best, editors can remember bookmarks, but these are merely locations in otherwise **completely uniform** text. In contrast, Leo scripts have instant access to full outline organization. But that means that my scripts have instant access to **my** organizations!!! In particular, another extremely fortunate side effect of using MORE as Leo's prototype was the notion that nodes have a headline as well as body text. This has allowed headlines to be descriptions of the data the node contains. The fancy term for this is that headlines contain meta-data; body text contains data. By convention, both Leo's internal scripts and user scripts use @x in the headline as a user- extensible type system. This turns out to be profoundly important. As I write this, I am struck by how fortunate I have been in developing Leo. First, that I was motivated by my inability to understand Knuth's TeX program. Second, that MORE was the prototype for Leo. Third, that I stumbled upon Python. And most importantly, that so many of Leo's users have made absolutely brilliant suggestions. In particular, Marc-Antoine Parent suggested XML for Leo's file format, Kent Tenney saw how to share subtrees, the great Bernhard Mulder convinced me to use positions (iterators), 'e' suggested what became @button nodes, and Ville created the bridge between IPython and Leo. It's been quite a ride. Thanks to you all. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
