Re: scope all wrong? in Mathematica 4.1
- To: mathgroup at smc.vnet.net
- Subject: [mg31857] Re: [mg31827] scope all wrong? in Mathematica 4.1
- From: Andrzej Kozlowski <andrzej at tuins.ac.jp>
- Date: Fri, 7 Dec 2001 05:56:53 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
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. In judge a programming language by its usefulness and not not by such matters as consistency and so on. 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 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. 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. 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. 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. 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). 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. > > > >