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