Hi Eduardo:

Many programmers refuse to document almost anything and expect the code to
speak for itself.  Or they throw random comments throughout their code that
don't help elucidate things.  The nice thing about most Elisp code is that
the inputs and outputs of functions are often pretty well documented, since
people learn from many good examples.  I support you in wanting to document
and explain things very clearly for your readers.  For most people,
Hyperbole is extensively documented down to the function-level.  But you
want an 'atomic'-level description of the internals of Hyperbole which I
think would be useful to only a very small population.

Good programming is about producing and layering clean abstractions that
sometimes must mask internal complexity and expose only the interfaces
necessary for use (could be a UI, an API or a class abstraction).  It's not
turtles all the way down as the 'physics' of different levels of
implementation varies.  Hackers do build from lego blocks; they don't spend
their time trying to deconstruct everything just to get comfortable with
every component they use, in general.  If you want to spend years trying to
wrap your mind around something a bit complex then read The Art of the
Meta-object Protocol many times.  Then, if you survive, come back to
Hyperbole and its call tree will seem simple to you :-)

Seriously though, I get that you learn and document differently than many
other people, so just do your own thing, your own way.  I am reminded of
the Hudsucker Proxy where the 'rube' is derided for his stupid idea until
later it turns out to be one of the most profitable inventions in history.
Maybe the rest of us just can't see what you see because of the way you
express it, though if we could, we would be enthralled.  I know a bit what
that is like!

Best of luck,

-- rsw

On Tue, Jun 28, 2022 at 12:48 AM Eduardo Ochs <eduardoochs@gmail.com> wrote:

> On Sun, 26 Jun 2022 at 21:50, Robert Weiner <rsw@gnu.org> wrote:
> >
> > So here is a simple implementation that is not unlike your own
> > though the functions are a bit simpler and more clearly documented
> > _without a listing of every possible test case type_ and requires
> > neither Hyperbole nor Org until you want to activate things as
> > buttons:
>
>
> Hi Robert,
>
> I think that the part in "_..._"s above deserves a detailed answer.
>
> I started using GNU/Linux in the mid-90s. Before that my favorite
> languages were Icon and Forth. In Forth I could do AMAZING things in
> less than 50 lines of code, but my programs would usually become
> confusing and unmanageable when they grew bigger than that.
>
> There is a famous book by Fred Brooks called "The Mythical Man-Month",
> and one of its chapters is called "Plan to Throw One Away":
>
>   https://wiki.c2.com/?PlanToThrowOneAway
>
> I took that slogan seriously. Most of the time when I realized that
> something that I was doing by hand could be automated I would write a
> first attempt to automate it - _as a prototype_, that I regarded
> partly a program and partly as a way to help me think how that task
> could be structured, and that would probably be "thrown away" if I
> needed a cleaner solution later.
>
> In Forth it was very easy to implement both strange interfaces and
> little languages, in this sense:
>
>   https://wiki.c2.com/?LittleLanguage
>
> In Emacs less so, but I could still do lots of funny things using
> eval-last-sexp to use sexps as buttons.
>
> When we are writing throwaway code "planning to throw one away" then
> using tests in comments is a very good way to document the code. And
> when I rewrite my prototypes I usually prefer to document them using
> text ***AND*** executable examples rather than just text. One of the
> effects of using this style is that the users of eev see that they can
> use that style in their notes too - and with that their notes become
> much closer to being "executable notes", in this sense,
>
>   http://angg.twu.net/eev-intros/find-here-links-intro.html
>
> than they would be if they believed that they had to write the docs of
> their functions as just text.
>
> You are sort of saying that having tests in comments is bad style.
> Well, it's not. =/
>
>   [[]],
>     Eduardo Ochs
>     http://angg.twu.net/#eev
>