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

[Stephen J. Turnbull]

>>>>> "Tom" == Tom Lord <address@hidden> writes:

    Tom> The architecture of software systems is very much about who
    Tom> can participate, in what ways, and what they can
    Tom> (practically) do.

That's my serif ("empowerment, empowerment"), exactly.

    Tom> To talk about how to restructure investment _without_ talking
    Tom> about jobs is naive.

Sure.  But talking about "unemployment" is not talking about jobs in
that sense, with people growing in capability, organizations
rearchitecting themselves to realize those capabilities.  Unemployment
by definition refers to a static notion of job, worse, one that no
longer satisfies the counterparty.

I agree, that was an omission of mine.  We do need to look at the
structural impediments that current corporate and industrial
organizations place on growth and productivity of people.

------------------------------------------------------------------------
Re: Can Emacs grow up?

    Tom> 1) Emacs lisp is slow by design.  Dynamic binding combined
    Tom> with buffer-local variables is the largest culprit.

    Tom> 6) Flow of control is poorly managed.  Busy programs freeze
    Tom> interaction.  Worse, the critical "program and user have
    Tom> isomorphic dynamic state" model is _not_ carried through in

"Program as waldo"?

    Tom> the area of recursive interact loops (where concurrent loops
    Tom> are far more desirable).

Yup, these are the killers.  I don't know if it would be possible to
rip out the event loop or the Lisp engine, and rebuild XEmacs from the
inside.  Technical and political problems both loom.

    Tom> 3) Emacs is too text-centric.  The "Emacs architecture" needs
    Tom> thoughtful extension for other media types.

I'm confused.  Are you coming to praise or to bury widget trees?

    Tom>    and, _more_importantly_, how do the necessary capabilities
    Tom> for such apps fit coherently into the "Emacs architecture" so
    Tom> that such applications can be written, extended, and
    Tom> documented with an ease comperable to Gnus or c-mode?
[...]
    Tom> Overall, does the "program and user have isomorphic dynamic
    Tom> state" principle generalize?)

Yes, I think the various aspects ("(point)", "(current-buffer)",
"(interactive ...)", etc) you talk about do generalize.  It's mostly
about taking advantage of human eye-hand coordination where that is
"serializable".  Eg, an application I simply can't see that
architecture working for would be an app that edits scores from a
piano keyboard or guitar neck.

The more implementational technical issues (process support and frame
layout) are currently being worked on in XEmacs, with a fair amount of
success AFAIK (but that's not my pidgen, I don't know if you would see
them as real improvements, and they don't manifest in the UI yet).

    Tom> I'm really skeptical that starting with the XEmacs source
    Tom> base is the best course -- but I fully acknowledge that it's
    Tom> a decision to make rather than a no-brainer.

Me too.  I think we see eye-to-eye on that, then.  Different emphasis,
I have obvious vested interest, we can deal with that.

If you decide to strike out in a different direction (de novo
implementation, I mean), let me know.  I might just come along.

------------------------------------------------------------------------
Re: motivation and psychology.

    Tom> I think that, for the most part, Emacs hackers are there to
    Tom> support people who use the current Emacs to do what the
    Tom> current Emacs does best -- not so much to take it in radical
    Tom> new directions.

Yup.  Less so at XEmacs, but still that's the majority.

    Tom> Overcoming executive superstition and then paying to produce
    Tom> a quality foundation.  That's what's needed.

Heh.  What the executives say is that the majority says "Moo."  We do
time and motion studies on the bovines, we adapt the widget tree to an
approximation of what they do a lot.  Each cow gives more milk, our
customers' bottom lines get healthy, and so does ours.

I don't think the executives are superstitious.  I think they see
funding experimental work on an architecture that only axe-wielding
hackers care about as distinctly unprofitable.  It really will not
lower their costs absolutely (90% advertising and executive
compensation, and I'm only half-kidding), relatively (if that's the
architecture that really gives an advantage, then competitors will
pick it up quickly) or improve the performance of their product from a
bovine point of view.  Ie, it's pure charity.

I think we need to talk to the NSF.

    >> The dedicated hackers are not personally interested in going in
    >> that direction.  They already have their hacking platform.
    >> Casual hackers would rather work in C# (or SWIG private
    >> libraries and call that an API) than harangue us to make
    >> existing features more accessible.

    Tom> Cause that's what the sexy rich kids do.

I think it's deeper than that.

    >> And although it has nothing to do with calibration of secondary
    >> gender-specific characteristics, even you turned to C to
    >> reimplement Arch.  Why not Python, or XEmacs Lisp (yes, we
    >> would very likely swallow a Lisp binding that linked to libarch
    >> as an option)?  Or Guile or systas scheme or scsh or clisp or
    >> Perl or Ruby?  Something deep is going on here.

    Tom> These are interesting questions but I think that language
    Tom> wars are OOT in this thread.

It's not a question of "language wars."  You keep saying "tla is not
arch, arch is not a revision control application, it is a FRAMEWORK".
But then you turned to a language whose main attraction is that it
takes frameworks and reduces them to applications that actually run on
real machines.  A language that requires an external debugger to
introspect at all.  A language that provides no way to point at an
object and get its documentation.  In short, a language that makes it
as hard as possible to hack.

If you do that, despite your sense that creating frameworks is
something we need to do _now_, and that arch is probably one of the
most important frameworks we can work on in the near future, I think
it's deeper than "language wars".  I have to think it says something
about the (lack of) superstition on the part of the executives.

------------------------------------------------------------------------
Thread to push on the stack:

    Tom> So, we can talk about how to deploy labor to effectively
    Tom> flood-fill niches as fast as they arise, with both very fine
    Tom> and very gross granularity.

OK, yes, that will take some thinking about.



-- 
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.