[Date Index]
[Thread Index]
[Author Index]
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.
>
>
>
>
Prev by Date:
**Re: scope all wrong? in Mathematica 4.1**
Next by Date:
**Re: scope all wrong? in Mathematica 4.1**
Previous by thread:
**Re: scope all wrong? in Mathematica 4.1**
Next by thread:
**Re: scope all wrong? in Mathematica 4.1**
| |