Re: [Gnu-arch-users] [OT] Architectural renovation

[Stephen J. Turnbull]

>>>>> "Andrew" == Andrew Suffield <address@hidden> writes:

    Andrew> On Thu, Aug 28, 2003 at 03:30:08PM +0900, Stephen
    Andrew> J. Turnbull wrote:

    >> I'm not discounting your _intuition_; I respect that highly.
    >> But the _words you say_ make me think "XEmacs" (ok, ok, to a
    >> guy with a hammer everything looks like a thumb, or whatever),
    >> and I just don't see the interest.  So something else is
    >> needed.

    Andrew> That one's easy. You need a problem that hasn't already
    Andrew> been solved, and that people actually care about. Making
    Andrew> improvements to a program which is already "adequete",
    Andrew> isn't one, especially with a barrier to entry that high.

You're missing the point, I think.  Tom is talking platform, I'm
talking platform.  XEmacs has the features Tom specified.  I'm not
saying people should hack XEmacs.  I wish they would, but I understand
why they don't.  I'm saying people should hack their other hacks in
Emacs Lisp, and file bug reports when the docs don't tell them how to
implement their hacks or the API makes them jump through hoops.  We
see far too little of that, and I don't know why.

Even within the project, we see people write kludgey, half-finished C
code for stuff that is easier to do in Lisp, and will actually work as
desired in Lisp, to boot.  There is something wrong with this picture,
and Tom saying "It's the architecture, stupid" is not enlightening me
as to what it is, let alone how to fix it.

    >> Starting from today's XEmacs, three man-years.  The features
    >> you mention are there, and performance is not a problem on
    >> today's 512MB RAM, 1 GHz machines.

    Andrew> *cough* XEmacs is sluggish as hell on my
    Andrew> 512Mb/1GHz/nforce2 box.

File a bug report.  Shouldn't be that way.  I _have_ a
1GB/2.4GHz/GeForceXX box, but after 4 months I still haven't bothered
to move my main editing/mail platform off the 256MB/450MHz/Mach64 box
that also runs my Coda server, a Coda client, Apache, and Slowzilla
(which is noticably slow on this box), not to mention the X server, a
font server, and a Japanese input method dictionary server, plus the
usual complement of random daemons.  I do use font-lock, but not on
Perl or Java (which both really strain the algorithms used, see below).

    Andrew> Especially with font-lock-mode enabled, there can be a
    Andrew> noticable delay between hitting a key and seeing the
    Andrew> response. It's possibly the single most irritating thing
    Andrew> about XEmacs.

Tell me about it.  But as near as I can tell, the problem is that the
algorithm used is fragile (N^2 with a big constant if you make any
mistakes in implementation, or if the text being parsed doesn't follow
certain style guidelines).  Doing something about this is 6-12 of the
36 man-months I mentioned.  You've picked the worst performance
problem in XEmacs, but it's due to choice of "parsing" "algorithm",
not the "platform".  I think that if somebody who knew what they were
doing would attack the problem at the roots, it would be fairly
straightforward.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.