[Axiom-developer] Developers and Axiom (was Re: typo in src/boot/Makefile.pamphlet)

[C Y]

--- "Page, Bill" <address@hidden> wrote:

> Ah, now wouldn't it be wonderful if we actually had a group
> of Axiom developers who were willing and able to do what you
> suggest! As far as I know, in two years I am the only one
> besides Tim who has ever committed anything to the main
> branch and I haven't done that in over a year... :(
> 
> I think we need a theory to explain why what you suggest has
> not happened yet. Here are some possible explanations (in no
> particular order):
> 
> 1) the literate programming (pamphlet) format is more effort
>    that most people are willing to commit to the project.

I'm not sure this is such a problem (at least, for me it is not - I
find it forces me to think about the problem and lets me document my
thoughts, which are both Good Things.)  I would like to have a better
editing environment for pamphlets, and I have somewhere the beginnings
of a literate-document Emacs mode based on work by Jay and Ralf.  I'll
have to get back to that and see if I can push it more towards proper
functionality.  (As a literate document it's probably literate to the
point of blathering, but since I didn't and don't know much about Emacs
I found it helpful - if and when it gets stuck into Axiom someone with
a better grasp of things can trim it down to sanity.) It needs to be
licensed under GPL because otherwise a truly insane amount of works
needs to be duplicated instead of being re-used from other sources, but
since Emacs itself is GPL hopefully for this one file that would be OK?

> 2) Tim's manual, re-check-everything-twice is intimidating
>    to other developers -- nobody wants to commit their
>    "mistakes" to the archive.

Heh - that part doesn't worry me too much, except the concern that I
might put in some epic stupidity that doesn't get noticed for a while.

> 3) Setting up and using arch with sftp write access is too
>    complex. It's easier to just let Tim do it.

Arch is certainly complex - I know I need to sit down with the
documentation and really study it.

> 4) There are not enough people who have sufficiently deep
>    experience with the Axiom source code and those that do
>    are already too busy doing other things.

Probably my biggest problem - my job has undergone a radical change in
the last month and a half and I have found myself with a lot more time
sinks and responsibilities.  Hopefully in the next few weeks things
will settle down into more of a routine again.

> 5) The centralized source code repository model sucks. The
>    current multiple-branch approach in the Axiom archive is
>    not being used effectively. People are still unwilling to
>    take responsibility for maintain a particular centrally
>    accessible branch.

I think, in my case at least, I feel like most of what I will be
capable of doing in the short term doesn't warrant an entire new
branch.  The emacs mode, for example, is just a single incomplete .el
file, not (yet) of much use to anyone.

Also, I think a lot of us are waiting on two things before we begin to
mess with Axiom in a major way:

1)  As I understand it, Tim is doing a rewrite of much of the core of
the system into modern, sane Lisp.  I rather doubt most of us can match
the skill and knowledge he brings to that task, and I know I can't even
come close.  I don't want to start mucking at that level when the odds
are high I would produce an inferior product.

Possible corrective action:  I don't know how accurate my perception of
what Tim was/is doing is here, so I might be totally off base. 
(Apologies to Tim if I am.)  But what might be a good way to ease new
folks into this would be to define certain sections of the code that
can be cleaned up without needing significant awareness of the overall
design issues of Axiom.  Not insisting on literate documentation at the
outset, but just point out some areas where budding or good lisp
programmers could help with minimal chance of causing harm or doing
work that might become redundant/irrelevant.

2)  Aldor vs. SPAD.  We are agreed that Aldor is the way to go in the
future, both for refactoring old code and creating new code, but we
still have no free Aldor compiler and no word on when we might have
one.  So I think a lot of us are holding off on major work until the
issue is resolved one way or the other.

Possible corrective action:  We've GOT to do something about this. 
Bill, IIRC you mentioned in an earlier email that a contact at NAG was
open to discussing the issue?  Without offense to Aldor.org, which I'm
sure has things going on behind the scenes we don't (and shouldn't)
know about, perhaps we should open discussions with NAG about the
issue.  I think there was work that occurred at Aldor.org post-NAG,
which would definitely be useful to us and should be pursued, but if we
can at least start working with A version of Aldor I think it will be a
Good Thing.  If Aldor.org's improvements can be eventually released we
will be in a good position to incorporate them into our branch, and in
the meantime the ambiguity of Aldor in Axiom can end and we can start
transitioning away from SPAD for real.

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com