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

[C Y]

--- William Sit <address@hidden> wrote:

> C Y wrote:
> > 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. 

OK, point.

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

There isn't - I'm just saying in a case like this, where neither side
makes an appreciable dent in the other, the way forward is code. :-)

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

Yep.  I think so far that's going rather well :-).  I'm learning a lot
from these discussions, and several offshoot questions are also of
interest - such as what objective "figures of merit" could be
established for programming languages?

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

I didn't mean to imply that.  Lord knows amount of code by itself is
not a metric for quality or respect - if that were the case Windows
could be considered a really high quality piece of coding art.  I'm
just saying that in an open source project discussion without code
ultimately goes nowhere.  I don't think that's a danger here, but it
has been known to effectively kill projects in the past.

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

I wouldn't consider it a failure.  This kind of discussion is education
in and of itself.  And if we should have to revisit the issue someday,
we can have everybody re-read the archives and save some typing :-).

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

Well, since I don't know Tim all that well yet (and he doesn't know me)
I just wanted to be sure I didn't come across incorrectly.

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

Spad does of course depend on the underlying modules, but shouldn't it
(in theory) not need to care how they are implemented?  Sort of the
same way ANSI lisp code should run in any ANSI lisp implementation,
without worrying about how the enviroment underneath it is coded up?

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

Some of the newer mathematical code might depend on language
capabilities that the older Boot code couldn't support, but I would be
surprised if things diverge that badly, particularly if we are able to
use Aldor as the primary language for new work.

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

Probably not.  I am hoping either SPAD or Aldor will present a fairly
stable, fixed platform from which to build, but I suppose that never
works out perfectly.  At any rate, having a working version to fall
back on is definitely a luxury compared to starting from scratch :-).

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

Point.

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

If I'm not mistaken, the approach Tim has taken so far with vol5 is
resulting in documentation that applies equally well to Lisp and Boot
code - at least, the level of documentation he has started writing.  If
it helps, perhaps the current state of included auto-generated lisp
code could represent proof that the current documentation is in fact
applicable to both Boot and Lisp code (where the documentation covers
such things instead of SPAD code) since they are demonstrably identical
at this stage.  If you parse out the lisp includes and build the book
again, viola - documented boot code.

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

Thanks!  I have always heard Lisp is real good at redefining itself to
particular tasks, so perhaps this is a good opportunity for it to do so
- that would leave pure lisp abilities for things like FFIs with
libraries and graphics, and still allow targeted coding for SPAD
purposes.  Eventually of course the ideal thing to do is rewrite all
relevant foreign libraries with the relevant research information in
Spad or Aldor, but for things like the CERN libs that could take some
doing :-).

The overall architecture of the Axiom system is definitely interesting,
even without language questions :-).  On Maxima I starting trying to
use Graphviz to map key relationships between systems, with the idea of
eventually creating successive nested graphs that would constitute a
roadmap of the entire system.  I didn't get much further than the
toplevel control loop, but even that was useful (to me anyway): 
http://maxima.sourceforge.net/toplevel.png

My original vision was that each package would have one of these types
of graphs as it's second page (sort of an "inside the cover" addition
if it were a book) that would allow a new programmer to immediately get
a feel for the workflow of this particular part of the system, and what
parts it relates to.  Maybe this could apply to pamphlets.  Also it
might allow programmers unfamiliar with how the system works to quickly
zero in on which functions were possibly relevant to a particular bug.
For real fun perhaps these diagrams could be autogenerated by the
SPAD/Aldor parser as part of the compile :-).  Of course, higher level
ones might have to be done by hand, depending on how smart the output
routines were...

Anyway, enough idle chatter.  Time for supper, and then some more
banging of the head on dimensional analysis.

Cheers,
CY


        
                
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com