Re: [Axiom-developer] Terms of Surrender (was: BAD tim)

[William Sit]

C Y wrote:
> 
> --- William Sit <address@hidden> wrote:
> 
> > Bill Page wrote:
> > >
> > > Tim
> > >
> > > On November 6, 2005 1:16 PM you wrote:
> > > >
> > > > in open source "advocacy is volunteering"
> > [snipped]
> > > I agree that "advocacy is volunteering"  ...
> >
> > Well, I don't! To have that as the defacto working principle is to
> > discourage people from commenting or advocating.
> 
> I think it is more like "if there are two firmly opposed points of view
> in a debate, if only one person is willing to put the coding time
> behind their ideas then they win the argument by default."  Or perhaps
> "only ideas with both merit and support can survive."

I would agree with the second interpretation. The party who produces code surely
will have a much larger influence on the eventual utility of the software, but
whether it "wins" remains to be seen. The market is littered with many well
supported software that got nowhere. I am sure while such software was at the
developing stages, there was heated debates on its directions. Just because
someone puts an effort to do the code is not my criteria for good software. 
Neither does that prevent me from appreciating the work that went into the
coding. Of course advocating an opposing viewpoint without producing code will
lead nowhere, but why should there be a defacto connection between the advocate
and the implementation? 

> I think Tim is saying (correct me if I'm wrong Tim) he things his
> reasons are good ones, he is not convinced by the counter arguments,
> and he is willing to support his ideas with the effort it takes to make
> them real.  This being the case it is unreasonable to expect him to
> undertake coding tasks he neither enjoys nor thinks are necessary
> simply due to a group vote.  

No quarrel with that. The choice remains his. I said, "We should all simply be
working together, each contributing what (s)he can, but with an open mind to
accept or reject suggestions after due considerations." and you agreed.

> If the opposing viewpoints are willing to
> put in the effort to actually implement their ideas then they gain much
> more respect and if they turn out well they can be incorporated into
> the project too.  I'm guessing that's what Bill was agreeing with.

There are different levels of commitment for everything. I am not as committed
to Axiom as Tim, Bill, Camm, Martin, and many others, are. If respect is
measured in the amount of code produced, then I am not in favor of that metric. 

> > All who submit their comments, experience, or voice their deeply
> > felt convictions ARE volunteering, but it does NOT mean
> > they should be also the ones to carry out and implement the code.
> 
> True.  But nor should those who are actually be doing the coding have
> to abandon their ideas - the name of the game is to convince the
> opposition that your ideas are good ones. [snipped]

Agreed, even if I am doomed to fail :-(.
 
> A lot of us have been arguing in a way that sort of suggests that if we
> argue to concensus we think Tim should/will shift his direction
> accordingly, and we have no right to expect that.  I for one wish to
> apologize to Tim if I have given him that impression.  

No, I don't expect Tim to only follow concensus -- that is not the sign of a
true leader. I respect his decisions even if I do not agree (at this time). I
trust and know Tim well enough that apologies are not needed. 

[snipped]

> The really important mathematical code is written in SPAD or Aldor, and 
> surivives regardless.

The running of Spad depends on the underlying modules. Having to backup to where
we are now in three years' time is not progress, but of course, I hope this will
never happen. In this case, it may be fortunate that we have a working code as
backup, but I bet that if we were to need to backup, the Boot code would have
been broken. In general, if we start writing code without a careful design, then
even though the resulting code can always be improved, the price may be very
high. Of course, I know the game is "release often, patch often" or something
like that. I guess a mathematician would never accept that.
 
[snipped]

> I will say that for my part, regardless of the final use
> of Lisp or Boot, I will stick with the Axiom project because the ideas
> behind transcend language and are in fact what make Axiom special to
> begin with.

Viva Axiom!
 
> Remember though, in this kind of discussion there is
> legitimate room for many different points of view - it's not like a
> mathematical problem where a correct solution can be demonstrated.

Even in mathematics, there may be different correct solutions.

Tim wrote: 
> > if we're going to enhance a language i'd much rather the time
> > and energy went into debating new ideas for the spad language.
> >

Bill Page responded:
> >  I agree completely.

William Sit commented:
> > This is a perfect example: people who suggest new ideas for the spad
> > language need not be the ones to implement them. In fact, possibly,
> > they are not even qualified to implement them. Let each contribute
> > his/her best.

CY wrote: 
> Definitely.  I think Tim and Bill mutually concluded though that the
> SPAD level, where most significant work will be taking place, is the
> most logical forum for language considerations.  Ultimately, both Lisp
> and Boot are "under the hood" and either can be made to function.  SPAD
> or perhaps Aldor will be the public face for Axiom coding, and has a
> specialized focus as well.

Precisely, that is perhaps my (and may be Bill's) rational that converting Boot
to Lisp is not a priority, documenting Axiom (and Boot, perhaps, so that
maintenance is possible) is. 

[snipped]
 
> Tim, am I right that the eventual goal is to have all significant work
> take place in SPAD/Aldor, and the Lisp supporting structure become
> stable and need little tweaking? 
 
[snipped]
> 
> P.S. - One idea I'd like to mention both to Tim and his debate
> opponents - what about the idea of keeping the Lisp like syntax, but
> defining macros or whatnot to add some of the "safety" that Boot
> provides in coding?  The result will still be Lisp, make no mistake (I
> for one really like that all I have to worry about is getting the right
> number of parenthesis, as opposed to other syntax mistakes, but that's
> just a personal preference) but perhaps some of what appeals to the
> Boot folks could be incorporated as macros or whatnot in the Lisp code
> itself, and in fact make the Lisp coding easier?  Tim, were you
> planning something like this?  We haven't seen much of your hand coded
> lisp yet, so perhaps you were already planning something like that?  I
> know that's a popular thing in Lisp, having the computer do work
> instead of the programmer, so perhaps something of the sort could be
> useful here?
> 
> Boot guys, maybe the thing to do is to enumerate what makes Boot a good
> tool for writing the SPAD compiler (or whatever) and look for a way to
> have Lisp macros or some such assist the programmer.  Boot syntax I
> don't think is going to make it, but if we take an ideas approach
> perhaps there is some useful mapping to be done which would appeal both
> to the original motivations for Boot and to an advanced Lisp
> programmer.  Rather than an all or nothing stance, perhaps accepting
> Tim's focus on Lisp and looking for ways to intelligently code Lisp to
> achieve the best (non-syntax) ideas of Boot would result in something
> everyone can be satisfied with.

I think your proposal is well worth considering by both sides. So far, we have
heard how bad Boot is and how powerful Lisp is. I am waiting for Tim to tell us
what the eventual architecture the Axiom system will be in his vision and how
Lisp supported that vision. I can still be convinced his way (and I will not
commit myself to coding for either camp -- that's full disclosure).

William