On Tuesday, June 27, 2017 at 12:24:24 PM UTC-5, Terry Brown wrote: > On Tue, 27 Jun 2017 11:27:27 -0500 > "Edward K. Ream" <edream...@gmail.com> wrote: >
> > How does that help new users? > > That's the problem with this proposal, it's so overloaded with benefits > it's hard to keep them categorized ;-) > This doesn't help new users directly, it just simplifies Leo's code > base and init. It does make it easier to write a @settings GUI > that's simpler for new users, but that's a separate benefit. > I was up in the middle of the night thinking about this, and afterwords had a vivid dream about leadership. In this post, I want to make sure that you, Terry, understand how and why I make the choices I do. As project leader, I have several goals that are in tension: - to encourage newbies to dive in and try new things. - to encourage experimentation, improvement and simplification where possible. - to keep Leo's user interface and scripting api as stable as possible. But I do not want my tolerance for ideas to imply that I am willing to sacrifice my fundamental priorities for Leo: 1. Clarity and simplicity of *purpose*. 2. Stability and simplicity of *user interface*, including gui and scripting api. 3. Simplicity of *code*. Sometimes, rarely, simplicity of purpose and code go together. The Mulder-Ream update algorithm is the most important example. Simplified code was an essential part of doing @clean. Much more commonly, simplicity of purpose results in difficult, complex code behind the scenes. In that case, the *only *proper course is to *prefer clarity and simplicity of purpose over code simplicity*. It is naive to think that code complexity is a symptom that something is wrong. I am willing to endure this misunderstanding among newbies, but I want you, Terry, to understand that code complexity is *not *a reliable guide to evaluating proposals. In this discussion, the first two priorities demand that Leo continue to use outlines to represent the hierarchy of settings. Yes, the code is complex. However, it mirrors inherent, *unexpected-but-unavoidable*, behind-the-scenes complexity. This is *not* going to change, even if, heaven forbid, someone decides to rewrite the startup code. This a "teachable moment" relating to other topics: 1. From very early days, simplicity of purpose demanded that Leo's core be independent of gui. This creates a small amount of complexity in the core itself, and more code complexity in wrapper classes of various kinds. *Without this code complexity it would have not been possible to create the npyscreen gui.*Early on, I often muttered to myself about the npyscreen code. The phrase that kept running through my head was 'a twisty little maze of rooms, all alike'. But I didn't waste *any *time complaining to the npyscreen people about their code. The npyscreen folks are *never *going to change their code. *They can't*, because it would break their users' existing applications. Creators of npyscreen apps must suck up the complexity and carry on. 2. Many years ago now, Leo moved to the "one node world" in which all data was held in vnodes, rather than a combination of (extinct) tnodes and vnodes. An essential part of the project was a transition plan so that existing Leonine scripts would continue to work. That transition went so well that only a few remnants of the old world exist. A major Aha allowed the *same *vnode to be expanded/contracted *independently *in different positions of the outline. New, complex, code created the valuable *illusion* that cloned (v)nodes have independent expansion bits. Similarly, root @<file> nodes contain complex data that create the *illusion* that (v)nodes may be marked independently. 3. Leo's settings-handling code is remarkably complex, and sometimes buggy. But it would be a huge mistake to think that this complexity is for nothing, and that somehow newbies' first ideas about settings can be taken at face value. I can not allow you, Terry, to make this mistake. *Summary* There is no Elysian realm in which all code complexities disappear. Simple user interface is an *illusion*, often created by very complex code. Using cff, git, pylint and pyflakes, devs can *discover* the complex, surprising, and unavoidable reasons why code is as it is. For example, yesterday I discovered a settings table that inited several commander ivars. My first thought was, maybe this table could go away. But no. These ivars appear all over Leo. It would be horrible to use c.config.getInt or c.config.getBool in their stead. So this table creates a major convenience in Leo's code, even while it complicates the startup code and (eventually) will complicate the reload-settings command. It a choice, and I think the tradeoff is a good one. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
