--- William Sit <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer