axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Axiom-developer] breathtaking vision


From: Tim Daly
Subject: [Axiom-developer] breathtaking vision
Date: Wed, 17 Nov 2004 10:06:51 -0500

Camm,

We're running into the limits of the lego model, I believe.
It wouldn't be reasonable to expect a user to collect the various
parts required to build Axiom although a subset of us consider it
the best path.

Consider larger "breathtaking", 30 year horizon projects like
the Crystal effort which collects and integrates dozens of tools. My
gut feeling is that the lego model collapses. We still need modularity
but we need it at a much bigger level. Sort of the prefab-house level
where somebody already integrated the kitchen and living room.

This is beginning to be clear with various projects. There is one
recently announced (Wired) that is a music studio similar to CakeWalk
or ProTools. For such a project you need sound generators, score
construction, codecs, CD rip/burn tools, A-D/D-A I/O board
controllers, midi tools, etc.  I have most of these around but the
Wired project is an integration problem. If I download these and
install them from rpms I end up doing a Wired rebuild every time
Lilypond (a scoring program) changes. Worse yet, that thrusts the
debugging problem onto me. In the case of Wired I just want a tool
that is comprehensive and "just works" so I'd rather they did the
integration with Lilypond and handled new versions.

The GCL case conflates two activities. The first is maintaining
GCL and the second is packaging axiom/maxima/acl2. From a GCL point of
view the axiom program is a big test suite. From the axiom point of view
GCL is flooring and wallboard. The fact that you do both activities makes
it feel like they're connected but it is entirely possible to keep them
at different levels.

Axiom is carefully tested each release with a particular snapshot of GCL
which is packaged with the system. There has been some flak for this
but we don't want users trying to debug failures due to GCL
changes.  So axiom is a stable release or so behind the GCL leading
edge but the users don't need to know that. And axiom developers are
the right people to either feed patches back to GCL or hot patch the
system for changes GCL doesn't want or need. If users try to assemble a
large, integrated system from parts they have to have these skills
which is unlikely in the larger world.

t








reply via email to

[Prev in Thread] Current Thread [Next in Thread]