On November 1, 2005 10:36 AM C Y wrote: > ... > I'd cast my vote for Lisp, somewhat because of my own > bias but mostly because Tim is accomplishing a lot > of stuff and I'm eager to see that continue. >
People seldom vote during a war :) but I agree that Tim is accomplishing a lot of stuff and I am also eager to see that continue. I believe Tim is very committed to Axiom and I doubt whether my haranguing him about his intentions to replace boot with lisp will have much affect on that. > ... That's the real beauty of the whole literate document > idea - the IDEAS will work regardless of the language, I think you put entirely too much faith in the concept of literate programming. The description of an idea is very different than the implementation of an idea. Very seldom, if ever, is a description written in a natural (human) language a sufficient basis of an implementation. There are always loose ends and forgotten details. And some people are much better writers than others (programmers are in general notoriously bad). I don't mean by this that literate programming is a not a good thing - just that it has its limitations. > ... > All mathematical work done in SPAD/Aldor doesn't have to > care one way or the other, so that work survives regardless, > and I'm really hopeful that we will reach a point where > most significant work in Axiom takes place at that level, > because that will mean Axiom is functioning as a mathematical > and scientific research platform. In my opinion we are already at that point. Or rather, we are anxiously waiting for more research-oriented users to show up. The work that Tim is doing now is mostly aimed at the longer term that will not immediately affect Axiom's suitability as a research platform. The issue of boot vs. lisp is a similar issue. It doesn't have any immediate impact on the usability of Axiom, but it (may) have a large impact on it's maintainability. > > > On November 1, 2005 1:16 AM Bill Page wrote: > > > > I agree with this. But from my point of view the BOOT > > language embedded in Axiom is much easier to "jump into > > quickly" compared to lisp, if your starting point is > > SPAD or if you had previously programmed in Python > > (unless you also happen to be a lisp programmer). > > Two points I wish to mention - 1) The CAS community is a > small subset of the total programming community, but within > that community Lisp is a much bigger deal than otherwise - > I think it is this community we are likely to attract, > rather than the general community I don't agree that CAS users are a subset of all programmers. I think a large number of people use systems like Mathematica and Maple without programming at all. Most CAS *developers* i.e. CAS users who write new applications within some given environment, of course must program in some language or other but then usually only at the highest level language available. I think only a small fraction of them might also know lisp. So if we target primarily the lisp programmers in this group, we are limiting ourselves unnecessarily. > 2) SPAD will only be a starting point for people who have > programmed a lot of SPAD code (not many currently) and also > want to work on the internals of Axiom the program. I'm > hoping this will actually work a bit in reverse -programmers > who are not up on the heavy duty mathematics side so much > (for high level math that's most of them, at a guess) will > start out by working on the Lisp side (with its documentation, > tools, etc. to help them getting started with Lisp) and then > graduate to working on the mathematical side, where learning > SPAD/Aldor will be part of learning to express high level > mathematics in a computer. I have a very hard time understanding what someone who does not know SPAD might be able to contribute to internal programming in Axiom. I don't think having a lot of experience in SPAD is necessary - only the basic syntax and usage plus a knowledge of how SPAD fits into the overall Axiom design is really important. In general it is not necessary to know a lot of mathematics to program in SPAD. However the Axiom library that is written in SPAD does represent a considerable amount of mathematical knowledge and to use it and extend it effectively does require some of this knowledge. In general I don't think trying to learn mathematical programming from the "bottom-up" so to speak is a good idea. I am certain that this is not what the original designers of Axiom had in mind. That is why SPAD is such a high level language when it comes to expressing mathematics. > Actual honest to goodness mathematical researches and scientists > are probably the LAST people who want to work on the guts of > Axiom except out of need for a working tool - they want to USE > it to do other stuff. Yes I agree. But in spite of that I do think that these people are still the mostly likely people who *will* do this kind of work. The other stuff that they really want to do is what motivates them to dig in and do whatever seems necessary to get the computer system to do what they need. Inevitable some of them adopt new "deeper" goals and spend most of their time implementing CAS internals and helping other people do what they really want to do. It seems to me that this is how it has gone in a very large number of cases since the beginning of this field. In fact I think the design of some computer algebra systems has sometimes suffered because those most motivated to do the work did not have particularly strong backgrounds in computer science, being perhaps excellent mathematicians but often self-taught in compiler design and user interface design. In this regard I think Axiom was exceptionally fortunate to have among it's developers people with both of these skills. > They'll be working at the Aldor/SPAD level, and any need to > go lower will probably get reported as a bug to be fixed by > the team. After all, how many scientists would request to > hack on the Mathematica source code? I think you really should take a poll. :) For example, from my experience I know a lot of researchers who would be very glad to get a chance to "hack" in the internal code of Maple. Very few of them would say they are entirely happy simply letting the developers solve the bugs. That is one of the reasons why there is a lot of pressure among CAS users for open source. > They want it to solve problems without their needing to do > that. As I said, I agree that that is what they want to do but not what all of them end up doing. > Since we want to become a rising force in the mathematical > community our goal has to be to provide a program where people > can focus on the math rather than the program. (Of course, > this is all speculation so it may or may not be worth anything.) If we could accomplish that goal, than I think it would be worth a lot. I think that Axiom comes closer to that goal than most of the other systems. > ... > > We must assume that the people who choose to work on Axiom > > already have quite a lot of other relevant experience > > including programming in several languages. > > I disagree - I think we want to appeal to mathematicians > and scientists, who quite often are NOT (or don't want to be) > computer programmers. I am sorry. What I meant was for this assumption to apply to people who want to work on the *internals* of Axiom, i.e. Axiom developers, not Axiom users. I agree with your statement. > > > I think this is what limits the potential developers much > > more than just learning another new language. > > Maybe I'm alone in making the distinction between Axiom the > programmer's challenge and Axiom the mathematical environment, > but I'm hoping that level of abstraction is possible because > it is likely to appeal to non-programmers. I think you are right in making this distinction but things are not quite as separable as you seem to imply. > > > > Maintaining both a library compiler (SPAD) and an interpreter > > (an integral part of the user interface) is inherent in the > > design of Axiom. BOOT is closely related to SPAD (or perhaps > > better said, SPAD is closely related to BOOT). So really > > there is no additional compiler to maintain. > > You mean the same compiler compiles both BOOT and SPAD > with no additional complexity added due to compiling BOOT? I mean that the problem of compiling BOOT is essentially a subset of the problem of compiling SPAD. In a sense BOOT is just SPAD but with a very limited set of types. So yes, conceptually speaking there is really not additional complexity added due to compiling BOOT. But from what I have seen and understood so far, Tim is right that the current Axiom code contains a lot of "cruft" and is in some cases quite far from optimal even though it works. So in the case of BOOT and SPAD I expect that a lot of the essentially similar code is actually duplicated or implemented in slightly different ways. If you look at some of the older SPAD code you can even see some of the original boot syntax appearing right at the surface, e.g. the "append"/[...] construct. > > > > I don't agree. I think maintaining a compiler as part of Axiom > > is essential. > > But mathematicians aren't going to want to work on a compiler > (it's hard to get funding for things like that.) They want to > do math. Ah, there's the rub. >... > I think wanting to make changes to Axiom itself will be a > different job from wanting to create new mathematical abilities. > It is quite possible there are others (like me) who are not > likely to make any spectacular mathematical contributions to > Axiom but are interested in providing features and functionality > for those who can. If you can complete your work on a units system for Axiom then I think that would potentially be quite spectacular. > For folks like me, the guts of Axiom being similar to the high > level language is pretty much totally irrelevant. In THAT > situation, there is a clear advantage to not using a custom > language, because hypothetically if I were a good Lisp programmer > (Granted I'm not at the moment) I could hook in FFI bindings to > the GNU Scientific Libraries. Starting from BOOT I haven't got > the faintest idea of how to proceed. Lots of things like that > will crop up over time, and Lisp already is working on the > problem of being able to interface with a large number of > foreign libraries via FFI. Exactly that issue came up in Kai Kaminski's work on Axiom UI. In that case Kai choose initially to use an entirely separate lisp process (in fact written in clisp rather than gcl because of ansi compatibility) and to communicate with Axiom via a pipe or socket. But gradually and during the latter stages of his work he discovered that he had to make changes in some boot code in Axiom in order to support Scalable Vector Graphics in the AxiomUI browser. Now as gcl approaches full ansi compliance and after Axiom is ported to the ansi standard (see another recent thread on this subject), I wonder if Kai might have used a different approach and written more in boot? > > In the end, Tim is being very productive, and that's a really > rare thing. I presume that you mean something like "productivity in open source is a rare thing"? Or did you really mean to imply that Tim is not usually so productive? :) I don't think so. > I'm cheering him on regardless - literate documents will > make sure Axiom survives any language. If someone wants > someday to do a new CAS, we want to set things up so that > to do anything other than start associating code with the > documentation part of the Axiom literate pamphlets wouldn't > make any sense at all :-). > I don't think literate programming is really such a "magic bullet", but I am all for the writing of documentation. Three cheers for Tim! And I hope that real soon now, some other axiom developers will come along to help out with this enormous task. Regards, Bill Page. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
