On Fri, Jun 17, 2016 at 1:02 AM, Tom <adatgyujto@gmail.com> wrote:

> Robert Weiner <rsw <at> gnu.org> writes:
> >
> > Or produce a coherent set of requirements and have an Emacs-familiar
> architect
> > and programmer (or team) work to produce new implementations with clean
> > data abstractions,
>
> In the real word these abstractions always lag behind practical
> development like adding new features, because development constantly
> moves forward amd while you come up with an abstraction, the new
> developments may already have surpassed that.
>

I have seen a lot of counterexamples to this where abstraction and
architecture are worked on first and the code that comes after far exceeds
comparable work that started with a code first, see what sticks attitude.
I am sure there are examples on both sides.


> In addition, emacs doesn't have a surplus of developers who have
> the ability and time to rewrite a huge piece of existing code, so
> striving for clean implementation rewrites is not really practical
> with the current developer base. There's lot of work to do already
> without rewrites too.
>

Fair enough, people have to be interested in attacking large problems and
volunteers choose what they attack.


> > Emacs should have excellent tools in these
> > areas.  Has anyone examined the org-mode code to see whether it is well
> > written or not?
>
> Org is an excellent, practical tool. That's why people use it.
>
> It may have room for improvement in its internals, but it can be
> said about other parts of emacs also. In software development there
> is rarely time to rewrite a big piece of existing code and it's
> especially true for volunteer projects with constrained resources.


It can be difficult to redesign running and deployed code but it has been
done many times and there is no specific timeframe.  It would be great to
hear from the authors on what they feel about the codebase and what parts
if any could use attention so people might look there.

Bob