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

[C Y]

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

> 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.  There are two ways to
advance a viewpoint in open source - one is to try and present an idea
on its merits, and convince the active coders it is a good one.  But
there is no guarantee that the developer will agree with you.  Failing
that, you can implement it yourself and demonstrate its potential.  I
for one think this debate is a very healthy one, and I don't think Tim
is trying to argue that people shouldn't be voicing their ideas.  I
think what he's saying (again, Tim please correct me if I'm wrong) is
that he has a design in mind, he is putting forth his time and effort
to bring it to fruition, and he believes in his design decisions enough
to try putting them into practice.  Discussion is fine, but barring
something both objective and compelling (which is virtually impossible
in this kind of debate) he has chosen his implementation path.

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.  I'm fascinated
by the question of the relative merits of the two design philosophies,
and am wondering if there is in fact any objective way to evaluate them
at all.   There have been extremely intelligent arguments put forth on
all sides, and it's been a treat to be able to witness such
discussions.  But when all is said and done Tim is his own master and
the active coder's decision is the one that the project goes with by
default, because it's a very, very bad decision that makes an active
project worse than in inactive one.  If we can't convince Tim that some
path other than the one he has decided on is better, based on the
merits, then that's fine.  There is certainly nothing stopping us from
experimenting ourselves, and if Tim wants to carry through with his
design I for one am thrilled.  I remember a quote from one of the Dune
books that I think went like this - "Most decisions can be made to
work, or if shown not to work can be corrected. But refusing to chose
any course results in certain disaster, because no new information is
gained and no progress is made."  One step backwards and two forwards
may be less efficient than three steps forward, but either is far far
better than no steps at all.  Whether Tim is making a step forward or
backward will be shown by events, but regardless making the step is
preferable to remaining deadlocked.  Remember, a worst case scenario is
simply a) we roll back the archive to the point at which the Boot code
is intact, and b) proceed from there.  The really important
mathematical code is written in SPAD or Aldor, and surivives
regardless.  

Ultimately, perhaps we can all agree that more important than either
Boot or Lisp is for Axiom to remain a living, vital project.  If we
move to Lisp rather than Boot, we'll survive.  If we go to Boot rather
than Lisp, we'll survive.  Either way, we'll learn new things. 
Ideally, most of the time we won't have to work in either Lisp or Boot,
but at the higher level of SPAD/Aldor where the really interesting
mathematical developments will happen.  Without active effort, design,
documentation, and new mathematical work no language choice will ensure
Axiom's survival.

I personally favor Lisp, but I will make no further attempt to join in
the argument.  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.  

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

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

> > > 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.
> > 
> > I agree completely.
> 
> 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.

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.

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?  (Sort of like the TeX source code?) 
I'm hoping that if McCLIM can eventually be used to define a GUI, we
can define a SPAD/Aldor API for interacting with and defining any
needed custom graphical elements, and then forget all about any
language below SPAD/Aldor except for maintainance issues.  But perhaps
I'm seeing it incorrectly.

Anyway, rant mode off :-)  Viewpoints aside I've been very much
impressed with the quality of thought and expression from all sides on
this list, and I think it speaks well of Axiom that it can attract this
caliber of discussion and thought.  Thanks for making this such an
interesting forum for discussion.

Cheers,
CY

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.


                
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com