Hi,
Nice to see how this discussion is moving forward.
I share the idea of longer names. These 3 letters don't convey anything
to me and I have to go always to the docs to remember what they mean (I
think g if for gui, and c for commander and no idea about p, but I'm
always unsure). That being said, I don't think is "bad style", is not
just "my style" and I prefer longer evocative names, but also I think
that Leo, as all artifacts, it's a product of its context. Live coding
and power tab completion features encourage longer names, but also the
community and authors practices (as in Pharo/Smalltalk) and sometimes
one looks his own code and thinks that the future self would write it,
in a complete different fashion. At least that happens to me with
Grafoscopio and is just reaching 3 years old, so I imagine how this can
be amplified in a 20 years old project like Leo.
What is a big advantage of Leo is what it enables: this community and
stuff you cannot do in any other software. This uniqueness is a profound
source of inspiration, as I have said before, and some inspiration is
found in the stuff that Leo doesn't have (live coding, simpler
collaboration and file format or even longer names), which doesn't
diminish in any way, Leo's history and community. Thanks for them.
Cheers,
Offray
On 11/01/17 08:02, Edward K. Ream wrote:
Recent criticisms of Leo and its architecture have been wildly off the
mark. The most ludicrous was the statement that 'c', 'g' and 'p'
should have longer names.
Here, I'd like to discuss Leo's /real /weaknesses. Some have recently
been exposed as I study pyzo's operation and code. I'll also explain
how they arose and what might be done about them. With one exception,
these have nothing whatever to do with Leo's classes or code.
*Collaboration difficulties*
Imo, this is Leo's main weakness in the world. It's not all that easy
to share .leo files. Diffs don't work well with xml files. Converting
from xml to (say) json, won't help.
Jupyter is far superior in this regard. The Jupyter project has had to
handle the usual security considerations. It appears that they have
come to a reasonable approach. This is one reason why the "Jupyter in
Leo" project seems important to me.
*Weak or missing basic editor features*
Pyzo shows just how much Leo's syntax coloring, code completion and
debugging capabilities could be improved. I intend to remedy these
defects this year, basing my work on pyzo's brilliantly simple code.
*Dubious decisions*
Most of these happened long ago, for what seemed like good reasons at
the time.
1. *Using wrapper classes for text editing*
The present Qt gui is, iirc, Leo's fourth gui. Two preceded Leo in
python. Previously, the python version of Leo used the much weaker Tk
gui.
The pyzo code shows just how big a price Leo has paid for the wrapper
text abstraction layer. Otoh, having a standard text widget greatly
simplifies the curses gui plugin. Still, the text wrappers do
complicate matters significantly.
2. *Commands are defined in the Commands class*
This class really should be called the Controller class, using MVC
<https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller>terminology.
Anyway, defining defining commands in the c class made sense
initially. Commands are clearly not parts of Leo's (data) model, nor
are they part of a view.
If I were to do things all over again, I would likely split 'c' into
'c' and 'c.commands' components. But that's not possible now because
it would break existing code. In my defense, the original (python)
design happened long before Python had decorators.
In fact, it's not even possible to split leoCommands.py into separate
modules. I've actually tried (twice) and given up quickly. Mistakes
would break Leo and there aren't nearly enough unit tests to catch
those mistakes.
3. *Underestimating regular expressions*
Almost all of the g.skip or g.scan functions could be replaced by
regular expressions. That would greatly simplify the code. I haven't
done this because there are bigger fish to fry.
The g.skip or g.scan functions could also be rewritten /using/ regular
expressions. But this /must/ be done safely. I will reject any pull
requests that do not contain strong unit tests that demonstrate
/complete /compatibility with previous versions.
*Outlines and clones complicate everything behind the scenes*
This is unavoidable. It's not a mistake and it's not the result of
bad design or poor programming. The flip side is that leo can do
things no other IDE can do.
But this /is/ still a weakness of Leo. Leo's code can be
complicated. For example, supporting an in-Leo debugger requires
Leo's goto-line-number code. No big deal: that code is encapsulated.
But there remain off-by-one errors that have to be fixed.
So that's it. I've confessed to you all of Leo's real weaknesses, as
I see them. Leo's behind-the-scenes complications do impact
day-to-day work. Otoh, this "weakness" makes all of Leo's unique
features possible.
But a balanced view would also mention Leo's successes. The main
design success is that it is /always /possible to revise the internals
of any class without major effects outside those classes. For
example, I'll be able to revise leoColorizer.py so it uses the
brilliant pyzo syntax coloring code without having to worry about
global impacts.
Finally, I'd like to say a few words about the supposed "haphazard"
nature of software design. Imo, such complaints are akin to
complaining that a novelist's characters seem to have a life of their
own. In fact, Leo's classes are driven by the tasks to be done. New
classes arise as new task arise. This is a completely natural
process. Leo's design means that new classes do not break old classes.
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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
--
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.
