On October 23, 2005 2:51 PM C Y wrote: > > --- Bill Page <[EMAIL PROTECTED]> wrote: > > > > I am sorry Clifford but your question strikes me as > > very peculiar. > > Sorry, I didn't mean to offend - clearly I'm missing > something fundamental. > > > As I said, I thought this was obvious. > > We all got nervous in Calculus class when a professor said > something was obvious ;-). >
No offence. In fact my comment was an admission on my part that perhaps what I wrote wasn't obvious except to me. I think you are right to raise your antennae when someone says something is "obvious". Sometimes this means either that they are too lazy to explain properly or that they do not in fact understand it themselves. Anyway, I think your questions are good ones and serve as motivation to write something that would otherwise not be proper expressed. > > So the way things are organized is SPAD built on BOOT built > on Lisp? And the core reason for this is that BOOT makes it > much easier to build SPAD than building it in straight Lisp > would be? Of course as Tim Daly would likely point out, that is a matter of opinion conditioned by personal style and degree of familiarity with programming in Lisp. But it is clear that many (most?) of the original Axiom developers seem to have held such a view. > > > From my point of view BOOT forms a very important > > intermediate level in Axiom because it allows programmers > > to write at a more abstract level than just low level lisp. > > This being the case, we should be very clear in the literate > documentation on the purpose for each language, the reasons > behind it, and the advantages to using it ... We all seem to agree that documentation is key to Axiom's future. The question is: how can we make sure that this documentation gets written? And after it is written, that it is accessible when someone needs it? I have been devoting some effort to building tools to make this easier, such as the new support for pamphlet files in the Axiom wiki http://wiki.axiom-developer.org/axiom--test--1 So now you can view the literate documentation for each module of Axiom source online and correcting or expanding the documentation is as easy as clicking 'edit' and then adding or changing whatever you want. But I am worried that just making it easy will not in itself make it easier to write useful documentation because in order to write documentation, you first have to understand what you are writing about. And without existing documentation *that* is the really hard part. > > So BOOT was made different from Lisp to allow SPAD to be > different? And the major objection to lisp is that it is too > low level? (Sorry if those are more dumb questions, I'm just > trying to get a sense of the modes of thinking involved.) Maxim1: "there is no such thing as an easy job" Maxim2: "there is not such thing as a dumb question" Yes, I think you understand my point. But it is not quite correct to call lisp "too low level". For many purposes lisp can be considered to be a very high level language. But the concept of level here is relative to the purpose. So, for the purpose of expressing abstract mathematics, yes lisp was too low level. > > > Footnote: > > > > 1\ Of course Aldor, as the next generation of SPAD, was > > actually written in "C" not lisp (that is another story). > > But the design of Aldor was inherited from SPAD. > > So if at some point Aldor becomes free and we can switch to > it, what are the implications for Lisp and BOOT in Axiom? > Ah, another very good question! Even with Aldor to replace SPAD, lisp and BOOT are still very important for the interpreter part of Axiom. The interpreter provides the user interface and must translate user instructions into operations from the Axiom library. It is possible to go further and to imagine writing the Axiom interpreter itself in Aldor. One can guess that this is one of the reasons that Aldor was specifically designed also to work as a stand-alone compiler and not just as the Axiom library compiler like SPAD. I do not know how much work, if any, has ever been done along these lines. Unlike changing Aldor for SPAD as the library compiler, changing the interpreter to Aldor would not be just an incremental change. The interpreter would have to be completely re-written from ground up. Personally I am not sure whether re-writing the interpreter in Aldor would be such a good idea. Certainly one would gain the advantage of easily working at the same level as the code in which the mathematical library is written. But outside of it's application as a replacement for SPAD, Aldor is still largely an experimental language. I think it's advantages and disadvantages relatively to lisp and BOOT or other high level object-oriented languages like Java, Python, Haskell and Ocaml are largely unknown. In a sense, this is where research in the Axiom project left-off when the money ran out... But it is one of the parts of Axiom that intrigues me most. > OK. In that case proper documentation becomes of paramount > importance, and I would say one of our highest priority tasks > (if BOOT survives the Aldor conversion) should be to get our > languages documented so we can have a reasonable expectation > of people being able to learn and program in them quickly. I don't think it is possible to say that too often unless saying it happens to get in the way of actually doing it ... :) > > So Lisp -> BOOT -> SPAD is kind of a "bootstrapping" process > wherein each level enables a more abstract or "high level" style > of programming than the previous stage? Hence the name "BOOT". > > I guess I'm used to the line of thought that goes "the fewer > programming languages in a project, the better" but that might > just be the consequence of not thinking about the magnitude of > the work involved in the Axiom effort - it could very well be > that the effort put in to learn to work in each layer of > abstraction pays off in increased productivity. I would say that "productivity" is not so much the issue as "creativity". Working at a higher level of abstraction allows you to concentrate on different aspects of a problem. And of course this mirrors how a lot of mathematics is also done. So this approach fits the application quite well. > > > I think that this "tension" was (and still is) an important > > part of the reason for Axiom's phenomenal success in the > > representation of mathematics by computer. Of course that > > might be just empty philosophy and maybe we really cannot > > know why one project succeeds and another fails or how to > > do it again... > > I think the effect of that tension is to keep people > continually arguing about and defending their design > decisions, which is likely to result in more robust > decisions in the end. Maybe that is a good thing, maybe it is a bad thing. I think we have to try to make sure that it does not lead to a stalemate and end up reducing everyone's motivation to make progress towards improving Axiom as a whole. I think one thing that we can use it for is to use it as motivation to continue writing about and hopefully, documenting more of Axiom. > I didn't mean to come off as overly aggressive, but I see reading > my original email I might have done so. Sorry about that - I'm > well aware I'm the introductory student in this project. Not at all. This might sound "soapy" but I do think that when you stop being a student is when you stop learning anything new. So I hope we are all students here. > Normally a concern in an open source project is handling things > in such a way that we attract developers, but this is not an > ordinary open source project and so I should worry less about > any barriers to entry posed by multiple languages and more about > how they benefit the quality and power of the result. > Yes, the "spin" you put on it is important. I think you are right to be concerned about how to attract developers to the Axiom project. One thing I am sure Axiom can offer open source developers is the challenge of working on a leading edge research project. And I think this is made even more enjoyable with the knowledge that this line of research already dates back more than 30 years. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer
