From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: Differences between Org-Mode and Hyperbole Date: Fri, 17 Jun 2016 19:54:51 -0400 Message-ID: References: Reply-To: rswgnu@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d551062feb10535821694 X-Trace: ger.gmane.org 1466207749 14240 80.91.229.3 (17 Jun 2016 23:55:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jun 2016 23:55:49 +0000 (UTC) Cc: emacs-devel To: Tom Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 18 01:55:42 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bE3bs-0007s8-RP for ged-emacs-devel@m.gmane.org; Sat, 18 Jun 2016 01:55:37 +0200 Original-Received: from localhost ([::1]:60699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bE3br-00077C-SS for ged-emacs-devel@m.gmane.org; Fri, 17 Jun 2016 19:55:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bE3bi-00075O-L4 for emacs-devel@gnu.org; Fri, 17 Jun 2016 19:55:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bE3bf-0007PE-KN for emacs-devel@gnu.org; Fri, 17 Jun 2016 19:55:26 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46583) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bE3bf-0007Ov-Gm for emacs-devel@gnu.org; Fri, 17 Jun 2016 19:55:23 -0400 Original-Received: from mail-oi0-f43.google.com ([209.85.218.43]:35272) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bE3be-0002sy-0M for emacs-devel@gnu.org; Fri, 17 Jun 2016 19:55:22 -0400 Original-Received: by mail-oi0-f43.google.com with SMTP id v7so28032693oig.2 for ; Fri, 17 Jun 2016 16:55:21 -0700 (PDT) X-Gm-Message-State: ALyK8tI3Q2IidGkVsjS4459mwIJp5bqAi1V5lXql9RvZAvqqpCbHioxFwh8b4CLS/XBKuxekdIZ8j7/lzkbGmA== X-Received: by 10.202.88.133 with SMTP id m127mr2919148oib.25.1466207721157; Fri, 17 Jun 2016 16:55:21 -0700 (PDT) Original-Received: by 10.202.91.131 with HTTP; Fri, 17 Jun 2016 16:54:51 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:204461 Archived-At: --001a113d551062feb10535821694 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 17, 2016 at 1:02 AM, Tom wrote: > Robert Weiner 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 --001a113d551062feb10535821694 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 17, 2016 at 1:02 AM, Tom <adatgyujto@gmail.com> w= rote:
Robert Weiner <= rsw <at> gnu.org> writes:
>
> Or produce a coherent set of requirements and have an Emacs-familiar a= rchitect
> and programmer (or team) work to produce new implementations with clea= n
> 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 a= rchitecture are worked on first and the code that comes after far exceeds c= omparable work that started with a code first, see what sticks attitude.=C2= =A0 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, peop= le have to be interested in attacking large problems and volunteers choose = what they attack.
=C2=A0
> Emacs should have excellent tools in these
> areas.=C2=A0 Has anyone examined the org-mode code to see whether it i= s 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 deploye= d code but it has been done many times and there is no specific timeframe.= =C2=A0 It would be great to hear from the authors on what they feel about t= he codebase and what parts if any could use attention so people might look = there.

Bob

--001a113d551062feb10535821694--