--- Bill Page <[EMAIL PROTECTED]> wrote: > Bob, > > After this reply, I promise to "give it a rest" ... :)
Heh - sorry, I can't resist replying. Ignore me if if you like - the short version is if I were to vote 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. Bill, one point is that the the current codebase already works and uses BOOT, so if at some point in the future we discover that Lisp was in fact a mistake (I doubt that but I'll postulate it for discussion) we can just come back to where we are now, grab the BOOT code, stick it in in whatever the current literate documents are in place of the Lisp code, and fill in the holes. That's the real beauty of the whole literate document idea - the IDEAS will work regardless of the language, and while it would be annoying having to redo the work in BOOT it would just be a question of implementing the ideas in BOOT, as opposed to puzzling out Lisp code and THEN writing them in BOOT. So I don't think it's irrecoverable in any case, no matter what happens, since we are in the decidely unusual position of starting not from scratch but from a fully functional system. 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. > On November 1, 2005 1:16 AM you 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 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. 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. 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? They want it to solve problems without their needing to do that. Since we want to become a rising force in the mathematical community our goal has to be to provied 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.) > > By writing in a language no one has ever heard of, the project > > will be doomed to those that already know it, and those that > > have a lot of time on their hands. Open source development > > is "itch scratching" and if it takes a month to figure out how > > to scratch the itch, most people won't do it. > > I cannot help but counter this view with another quote from > Norvig: > > Teach Yourself Programming in Ten Years > > http://www.norvig.com/21-days.html > > "Researchers (Hayes, Bloom) have shown it takes about ten > years to develop expertise in any of a wide variety of areas, > including chess playing, music composition, painting, piano > playing, swimming, tennis, and research in neuropsychology > and topology." > > He claims this applies to programming as well and I doubt > that he would have any objection to adding computer algebra > systems to the list. I agree, but isn't this in fact what Axiom is trying to address by bringing the program closer to the mathematics? To allow researchers who have put in the ten years to get good at mathematics to use a significant part of those abilities as is in Axiom? The goal is to allow mathematicians to be mathematicians without being programmers any more than actually necessary to completely specify their problems, which is one of the brand new things about Axiom. > Of course we aren't talking about learning to program just to > make small changes to Axiom. 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 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. > > Complexity of software scales as exp(size). Doubling the > > size (maintaining a compiler too) means far more than double > > the work, and will require far more than double the coders. > > 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 don't really care what language is used. I've used around > > 40 in my life and can learn another. But Axiom will die if it > > is necessary to maintain a compiler also, > > 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. > > and it will die if other people can't pick it up quickly and > > contribute. KISS. > > That might be true. But I think we need to be very clear what > you mean by "pick it up". If you mean "learn to use Axiom to > solve some relatively simple algebraic problem", then I don't > think Axiom is much worse off than any other computer algebra > system in that regard. There, I agree. > From there to programming Axiom library > routines is not such a big step. Also agree. > And there are other things > that one would need to "pick up" before one could start making > changes to Axiom itself. True. But 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. 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. In the end, Tim is being very producive, and that's a really rare thing. 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 :-). Cheers, CY __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
