When I finished swimming yesterday, the thought appeared that *Leo isn't nearly good enough*. This was a *constructive* thought, as I'll explain here. These questions came to mind:
- Why must we be continually reloading Leo? - Why must we reload settings every time Leo starts? - Why must code be this messy? - Why can't we put unit tests near the code being tested? - Why can't we use Rust to speed up Leo? - Why can't we use javascript, or prolog within Leo? - Why can't we catch errors sooner, with less harmful effects? - Why is auto-completion so hard? - Why can't we change Leo's appearance on the fly? The dream is to see changes safely and immediately, without reloading Leo. Vitalije, Offray, Reinhard, Terry, among others have voiced similar thoughts. These dreams are worth working on. Vitalije has complained about the slowness and complexity Leo's settings. These complaints are perfectly valid in the context of having big dreams. Loading Leo without having to reload leoSettings.leo, myLeoSettings.leo and a theme.leo file is a reasonable goal. Offray has compared the Smalltalk/Pharo world with the Python world, and argued convincingly that Python can't emulate everything that Pharo can do. *Dreams meet reality* Right now, seemingly easy changes can be arbitrarily hard. For example, Leo should have a toggle-gutter command, so that the debugger can ensure that the gutter is visible even if @bool use-gutter is False. Doing this requires requires complex changes inside Leo's gui code. I have just verified changing this setting and then doing reload-settings does not work. Perhaps it should, but that's only a tiny part of the problem. As another example, avoiding loading settings files is likely to add considerable complexity. I am not aware of any IDE that comes close to meeting these dreams. I don't think Pharo counts as an IDE, but in any case I am not prepared to rewrite Leo in another language. I don't have the time or energy to do that, nor do I think adding Leo support to another IDE makes sense. *Keeping the dreams alive* The dreams are valuable, whatever happens: 1. They point to places where Leo could be significantly improved, even if it means an *increase* in complexity behind the scenes. However, it's possible to imagine that some of the dreams could even reduce the complexity of Leo's code. 2. They stimulate thoughts that would otherwise not arise. I like working on these kinds of challenges. Leo came about because I couldn't understand literate programs. 3. They encourage us to explore the literature on similar topics. *An irony* I have often said that we Python programmers act as if we *did* know the types of all objects. But this mind set turns Python into something akin to Java or C. Bye bye flexibility and dynamism. Python's classes are more sclerotic than we might like, a point that Vitalije has made. *Summary* Each of the questions above suggests new possibilities for Leo. They challenge all aspects of Leo's design and code. I'll write separate posts discussing some of these questions. I am not going to rewrite Leo in another language. I *am *willing to make large, incremental, changes to Leo. Your comments, please. Feel free to summarize your previous comments. Now is the time for dreaming. 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
