Re: Differences between Org-Mode and Hyperbole

[Eli Zaretskii <eliz@gnu.org>]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Sat, 02 Jul 2016 11:13:50 +0200
> 
> Eli Zaretskii writes:
> > It [Org] includes several features that are very loosely coupled.
> 
> The coupling of these features is via Org the document format, not Org
> the major mode.

Yes, I know.  But the format requires one to use some minimum amount
of commands and customizations, before it becomes usable enough in
practical use cases.  And those are part of Org the mode.

> > E.g., what does spreadsheet-like table have to do with
> > outline-structured notes?
> 
> That people writing an outline expect the ability to include tables
> without needing to get out of the document they're editing?

Like I said, use cases where these are useful in the same document
clearly exist.  That's not the issue here.

> > What does the ability to embed source code in several programming
> > languages has to do with diary features?
> 
> See above.

See above.

> > Sure, we can come up with use cases where it makes sense to use these
> > features together in the same file, but I think use cases where they
> > are unrelated are much more abundant.
> 
> Cases of using a computer that do not involve the Emacs are also
> abundant, I hope you agree that this as not an argument against Emacs.

You are missing the point.  The point is how much of the basic
functionality one needs to master before they can use a single feature
of a large package.  If the answer for your Emacs analogy is "too
much", then it _is_ indeed an argument "against Emacs".

> > Btw, it might be relevant to point out that quite a few features
> > originally provided by Gnus were over the years refactored into
> > separate Emacs packages, and are nowadays available in general-purpose
> > subdirectories, like lisp/net, lisp/mail, and others.  Perhaps the
> > most prominent example is Message mode, which was several years ago
> > made the default Emacs mail composing mode.  This tendency continues
> > with Gnus to this day.  My interpretation of that is that Gnus, too,
> > had/has some features included that shouldn't have been there in the
> > first place _as_part_of_Gnus_.
> 
> Hindsight is 20/20.

We _are_ talking hindsight here.  This is not a discussion of whether
the Org designers made the right decisions when they made them.  This
is a discussion about whether _in_hindsight_ some alternative design
could have yielded a better result.

> > As I said already several times, there's no "digging" here.  This is a
> > discussion about design principles of large Emacs packages.
> 
> I've yet to see that discussion starting.

Sadly, I agree.

> > Well, here's where we disagree.  Tight integration of unrelated
> > features is not a good thing, IMO, since it makes learning each one
> > harder, and it makes maintenance more vulnerable to a loss of a single
> > central individual who knows all the ins and outs.
> 
> More user POV, which you said was irrelevant.

No, I did not.  What I did say that we need to look at this via
software designer's eyes, using the resulting user experience as the
test.