Martin Rubey wrote: > I have used Aldor, SPAD, the Aldor interpreter and the axiom interpreter quite > intensively, and found the combination Aldor + axiom interpreter formidable. > > What I found most impressive is that the axiom interpreter is designed well > enough to work seamlessly with new packages.
Since you do find the axiom interpreter helpful and indeed getting the types right (your examples are not particularly impressive to me because the names and signatures are quite unique and only the arguments need be matched), why aren't you and Ralf in favor of improving the compiler so that the compiler can be equally helpful? Why should the human programmer be forced to manually perform what the interpreter is doing so well (and most likely can be even improved)? Currently, to translate from interpreter language to compiler language, one needs a combination of ")show," ")display," ")set mess bottom on," ")set message auto on," and hyperdoc searches to identify packages and coercions. This process is repeated every time there is a compiler complaint. This is time that could be spent for documentation instead. Thu, 16 Aug 2007 01:35:08 +0200 Ralf Hemmecke wrote: > Interpreter and compiler language are > identical and identically strict. No auto-coercions. > You cannot expect that it will be painless to implement library > code from fuzzy experimental code. Why not? All code is experimental until it is final and frozen. Documentation is constantly being added and revised. I don't consider documentation "pain," because it is necessary. I do consider spending time to rewrite interpreter code into compiler code a waste of time and therefore "pain". (Compare this with the pain associated with style changes for bibliography items when bibtex is not used.) As long as the interpreter language (what you call experimental language) and the compiler (or library) language are one and the same, the pain level would be reduced substantially (to zero if the two are 100% compatible). Of course, we should not let the compiler "guess" like the interpreter currently does, but the compiler can "help" to provide a set of choices and recommended selections (much like a spell-checker presents a list of alternatives to let the writer select or decline). So in my dream editor for Axiom, there will be a pull down menu to "type-check" and "package-check". This "help" should be the same whether one is "experimenting" or writing library code (and ideally, even when writing a pamphlet if pamphlet is the de facto source) . This help need not be "automatic" as in the current interpreter. In all other languages I have experience, the "experimental" and the library languages are one (Maple, Mathematica for example). > William, you should really try to experience how it is to program in > Aldor. Sure you will feel some pain in the beginning, but that will not > last long. You will love the clarity. Clarity is achieved by the programmer, not by the language and Axiom code can be just as clear as Aldor code. What the Aldor compiler does better is its better diagnostics and arguably a more expressive language. Learning a new language is not "pain." For Aldor, the "pain" comes from missed Axiom algebra libraries and incompatibilities (much like between Maple and Mathematica). I was at IBM Research when the new compiler for the precursor A# of Aldor was written. At that time, I was using Scratchpad II, the old compiler, which was roughly the same as the current Axiom compiler. I was able to write my programs without knowing lisp, but there were bugs and design-related suggestions that the team would not fix or modify because it was working on the new language and compiler. I mention this because I am afraid the same thing may happen again: instead of fixing the problems, it would be more fun (and probably easier to obtain grants and publish papers) to start a new language, promising to be better. Certainly, there are good reasons to do that, too, especially if the problems are due to poor design rather than implementation. Nonetheless, a new language that is not 100% backward compatible and without automatic conversion facilities alienates the earlier programmers and obsoletes the old code base. The three incompatibles (interpreter, Spad compiler, Aldor compiler) are, I believe, the main reasons why the commercial version did not receive wider popularity. This triad of languages becomes confusing to most users, old or new. The few gurus, with due respects and admirations, are great hackers (in addition to being excellent mathematicians and computer scientists). But hacking is only a good skill to find bugs or get a program working, not essential, and indeed, may even be detrimental, to write readable programs. Hacked code distracts and hides the natural flow of mathematical or computational ideas. It would make documentation "extra painful" to write, and thus often, not written. The question is: do we want Axiom/Aldor to remain the havens for hackers or make it palatable to general researchers, whose hacking skills and stamina may be, on average, much less? William _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer