Re: scope all wrong? in Mathematica 4.1
- To: mathgroup at smc.vnet.net
- Subject: [mg31859] Re: [mg31827] scope all wrong? in Mathematica 4.1
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Fri, 7 Dec 2001 05:56:56 -0500 (EST)
- Organization: University of California, Berkeley
- References: <F40C1CE0-EAAF-11D5-93E0-00039311C1CC@tuins.ac.jp>
- Sender: owner-wri-mathgroup at wolfram.com
Andrzej Kozlowski wrote: > Of course you are right that I am a mathematician by training and not a > computer scientist. Clearly our perspectives on programming languages > are different: I tend to look at them as tools, to be used in doing > mathematics, not as formal systems to be studied. I agree with you entirely on programming languages being tools. I do not study programming languages, I use them. I prefer my tools to be correct, however. In judge a > programming language by its usefulness and not not by such matters as > consistency and so on. In that case you are missing the point. The usefulness should be in the specifications of the language --- that many people can use the same tools. If all you are saying is "I used this language to write this program and it worked for me, even though it might not work for you if you happen to use it for a case where the answer is not known in advance and can't be checked" then I say this language should be judged "not very" useful. What can be "proved about it", is usually less > interesting to me, at least in my capacity as a user of a programming > language. Of course there are situations when it is no so. It so happens > that I first learned Lisp from reading Greg Chaitin's "Algorithmic > Information Theory". Before that I had only only had used Algol and > Pascal which I learned as an undergraduate, and when I read Chaitin's > book I was amazed there could be a programming language that was so > perfectly consistent and well defined that one could prove theorems > about it. That is indeed very beautiful, but hardly useful for doing the > sort of mathematics I am really interested in. The fact is that several computer algebra systems were written in lisp (a more advanced version than Chaitin;s of course). These include Reduce, Axiom, Macsyma, (and probably 12 research programs of the past). The whole situation > reminds me of the traditional division in mathematics between these > mathematicians who consider foundations of mathematics as an important > and central subject and those who think of it as something totally > unimportant. Suppose an unresolvable flaw was discovered in the > foundations of Mathematics, say a basic inconsistency in all known > axioms of set theory. What would be the reaction of people studying > partial differential equations? Most would just shrug their shoulders > and go on doing what they were doing, and in my opinion would be quite > right to do so. These subject do not rest on the "foundations", it's > only the people who who work on foundations who flatter themselves that > it is so. You talk of mathematics in terms of "axioms". Of course there > are many mathematicians who think in this way. But there are many more, > including myself (and I mean pure mathematicians dealing with abstract > objects like manifolds or complexes) who hardly ever mention this word > in their work. But you are using as a tool, a program in which transitivity of equality fails. That is, a==b and b==c does not imply a==c. This matters even in partial differential equations. You are using a tool in which the identity function Function[x,x] is not a function, but a kind of pattern in which the basic notions of free and bound variables -- essential for referential transparency -- the substitution of equals for equals -- fails. Now of course if all your programs are not really programs, but commands like if you see f(x,x) change it to g(x). or commands like "compute the totally understood result of the polynomial resultant of two polynomials with exact integer coefficients" then you are OK. If you try to build a robust system of substantial complexity, the tools must not have hidden flaws. > > So my reaction to your examples and to most of your comments is that > them may well be true but are hardly relevant to me or the vast majority > of people who use Mathematica. The vast majority of people who use Mathematica are still learning integral calculus. The vast majority of people who use computers today are probably surfing the net looking for pornography. Not a good argument for excellence! You say that the fact that something is > documented and called a "feature" does not stop it being a bug. But that > is only true if that "bug" prevents you from doing something you might > want to do. When the manual says "don't do it this way, do it that way", > the argument that other programs do it the first way and so not being > able to do it that way must be a bug, does not seem to carry much weight > to me. > > I find Mathematica more useful than Common Lisp because I can, for > example, combine Groebner basis computations, with graphics and > evaluation of integrals, all in the same program. I can do this in Lisp, since Macsyma has those pieces, though these parts of Mathematica are probably OK. Well actually, the evaluation of integrals has problems... Of course these things > could be added to Lisp, but they are not. Moreover, the rule based > programming style of Mathematica is very much more efficient for the > kind of things I do, most of the time. Let me make this concrete. At > this time I doing research which involves computing invariants of > actions fo finite groups on certain polynomial rings. I have written a > "package", or rather just a collection of functions, defining the > Steenrod operations, Dickson invariants and so on. I use this together > with the built in GroebnerBasis and other polynomial algebra package. > All of this just in about two printed pages. I also happen to have a > Lisp program which does basically the same thing. It's more than 10 > pages long and is most of the time slower. There are countless other > examples of this kind. In fact I only use Lisp when I need to do > something that will require huge amounts of memory, because in such > cases Lisp's recursive programming seems sometime the only way to go. > But this has nothing to do with the consistency of Lisp and Mathematica > and nothing to do with scoping. > > So to sum up: I consider the examples that you sent to be of some > theoretical interest and 0. practical importance. I think we can agree to disagree. But doing these "theoretical" things correctly would not be expensive. It would just have required Wolfram to know a few things when he dictated how the system should work. I think the idea that Wolfram was pursuing, that the language he designed was important, the application "Mathematica" just an example, is deeply flawed. I think that people who teach Mathematica as a computer science "programming language" are doing a grave disservice to the science of computer science. Just as those people (who still work in physics labs) who think that Fortran is the best language, even though it is the only one they ever used. And that their opinion, because they are physicists, is therefore valuable. TO justify this view > I looked at some of my hundreds of Matheamtica notebooks to check how > often I used Block and Module. It was I as expected, almost exclusively > when writing something for the mathgroup. I am now not even sure how I > came be indoctrinated with the idea that one should do that! The > programs I write for myself consist of lots of short, often one line > function definitions and function calls. In fact I often use global > variables and Clear them afterwards. It seems to me that this is the > natural way to use Mathematica and I expect that most users do the same. > Given that, is it surprising that I consider yor message of little > importance. Maybe Mathematica scoping is "all wrong" but if so then > "scope" is hardly an important aspect of Mathematica. Suppose it could > be "fixed", would it make Matheamtica a more useful tool? I doubt it. > Moreover, any human and other resources devoted to this task would have > to be diverted form other things, like mathematical applications. If one > has to choose between improving Mathematica scope and its ability to > solve differential equations, how many users would choose the former? > Very few I believe. I think in the end this is the central issue. Of > course I would like Mathematica to be perfect in all respects, but > fixing the "foundations" is less important to me than expanding its > frontiers. Like mathematics, Mathematica is not a vertical structure > that can be brought down by some weakness of its foundations ( or at > least not this particular weakness). I actually disagree. Look at the disclaimer at the front of the book that says not to use Mathematica for computations involving life, or property. Regards RJF > > > Andrzej Kozlowski > Toyama International University > JAPAN > http://platon.c.u-tokyo.ac.jp/andrzej/ > > > > > On Friday, December 7, 2001, at 02:01 AM, Richard Fateman wrote: > >> >> >> Andrzej Kozlowski wrote: >> >>> This sort of arguments seem to be a regular feature on this list. I >>> do not feel like going into detail because I remember all this having >>> been done before more than once. There are however three general >>> points that I would make. >>> 1) All the "unexpected" outputs are exactly as would be expected by >>> anyone who has a fair grasp of the Mathematica language and can be >>> supported by the documentation. Therefore they can't be called bug, >>> at least not in the sense that I understand the term. >> >> >> >> Documenting a bug as a feature does not remove it, in my opinion. >> My guess is that your formal training is not in computer science, >> and that you have not taken a course in (say) design of programming >> languages. >> >> In mathematics it is possible to construct formal systems based on >> any set of non-contradictory axioms, and there is only a momentary >> pause in the stream of publications when someone points out that >> the defined system is useless, or perhaps vacuous. A set with no >> elements has many properties, and if you didn't realize it was empty, >> you could have something quite interesting! >> >> In programming, there is not so much that is arbitrary. We don't >> want people to be surprised by the consequences. Sometimes there are >> legitimate choices in design, based on different perspectives of >> (say) scope: which is most useful/efficient. Sometimes there are >> just "bad" designs. I think of these as really bad bugs, especially >> when they are defended. (Maple, for a long time, had some such >> bugs. To their credit, they eventually fixed them. Probably because >> one of the designers left the company.) >> >> (This is not to say >> >>> that there are no bugs in mathematica, it certainly has its fair >>> share. Just that none of these are.) >> >> >> >> Certainly we can agree to disagree here. >> >> >>> In fact the first two cases are Mathematica "standard errors", >>> discussed in this group a countless number of times . If a >>> Mathematica beginner came up with them I would refer him to the >>> Mathematica Book. The other examples are more subtle but highly >>> contrived. In the unlikely event that that a beginner would be >>> troubled by them my reaction would be to say "why on earth do you >>> want to do that?". >> >> >> >> >> Certainly you are familiar with the importance of counterexamples in >> mathematics. >> If someone proposed a new axiom system for geometry, and you showed that >> it lead -- in certain singular instances -- to contradictions, then >> you would have a valid objection to that system. You would probably >> not have much confidence in anything proved in that system. >> >> If someone proposed a new programming language and I showed that it >> lead -- in certain singular instances -- to nonsense, then I would >> have a valid object to that language. I would not have much confidence >> in anything programmed in that system. >> >> >> >>> 2) One can certainly argue about the good and bad points of the >>> design of a programming languages. However, to a large extent this is >>> a matter of what one is used to, how and how often one uses a >>> language and of personal taste. >> >> >> >> To some extent this is true. Just as in mathematics one can use >> a notation f'(x) or d/dx(f(x)). >> >> For example, you have written on the subject of Block >> >>> and Module before, and I have found that some of the things that you >>> criticize are in my opinion among their strongest points, allowing >>> many constructions that are difficult to achieve in other programming >>> languages. >> >> >> >> >> I don't know what other programming languages you are referring to here. >> You mention Common Lisp, which allows a far more complete and consistent >> programming perspective. If you are saying Mathematica as a programming >> language is better than Common Lisp, I think you are being blinded by >> application programs, and superficial syntax. These can of course be >> added to Common Lisp, and it does not require breaking the semantics >> to do so. >> >> >>> 3) I can imagine that there may be good reasons for being interested >>> in translating between different programming languages. I do not know >>> much about that. >> >> >> >> Often this is appealing because people say "mathematica is too slow, >> can it be translated into C" or "I would like to run my Maple program >> along with someone else's Mathematica program". >> >>> However, as a matter of practice I find "translating" a bad idea. I >>> use two languages, Mathematica and Common Lisp, the first very often >>> and the second when really needed, and I make an effort to >>> consciously avoid trying to translate between them since this is the >>> surest route to inefficient programming. Both languages have their >>> unique strengths and are ideally suited for different purposes. The >>> Mathematica language is certainly unlike any other but I really do >>> not see why this is a bad thing. And after all, as you yourself have >>> written, one is always always free not to use it. Since you have >>> already made this point what is the point you are trying to make now? >> >> >> >> I am continually surprised at how bad the design is in respect >> to certain programming language issues. As you know, I wrote a >> parser / partial evaluator for Mathematica (MockMMA) in Lisp. >> I have not run these examples in it, but I expect that it will >> either (a) operate in the same way as a consequence of my having >> programmed the order of evaluation and binding in the same way >> as Mathematica, or (b) operate in a different way, reflecting >> my (mis)understanding at the time of how the simulation of parameter >> binding by pattern matching is supposed to work. My expectation >> is that at time time I wrote MockMMA, my understanding of >> (a) the syntax >> (b) the pattern matcher >> (c) the evaluation >> was as thorough as any but a handful of people. >> That is generally what happens when one implements a system: >> all the details must be tied down. >> >> As programming language designers, we are not constrained >> to physical reality (as is the case with some physicists). >> we are not constrained to study actual biological animals >> and plants (as is the case with some biologists). >> We can construct our own systems. Somewhat like mathematicians >> but with a different esthetic sense. >> >> The language design of mathematica, presumably done by >> Wolfram, has many interesting features. It is possible >> that these same features could be assembled in a system >> that does NOT botch scope. MockMMA allows one to experiment >> with such changes, though frankly no one (including myself) >> has pursued "a new Mathematica evaluation mechanism" using >> this tool. >> >> >> I do not know how the system would have come out if Wolfram >> had (for example) really understood lambda calculus or >> lexical scope. If he had read the Abelson-Sussman book >> Structure and Interpretation of Computer Programs, >> I think Mathematica's language would make more sense. >> As it is, Wolfram picked up some of these ideas but did not, I >> think, understand them. >> >> >> >> >