Re: Mathematica and Lisp
- To: mathgroup at smc.vnet.net
- Subject: [mg129549] Re: Mathematica and Lisp
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Tue, 22 Jan 2013 02:40:46 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-newout@smc.vnet.net
- Delivered-to: mathgroup-newsend@smc.vnet.net
- References: <kcqkv4$lq5$1@smc.vnet.net> <kct7fj$sgo$1@smc.vnet.net> <kd03ej$6dl$1@smc.vnet.net> <kd2ltk$cog$1@smc.vnet.net> <kd7tsg$q3s$1@smc.vnet.net> <kdanpt$3d5$1@smc.vnet.net>
On 1/17/2013 9:49 PM, David Bailey wrote: > On 17/01/2013 04:15, Richard Fateman wrote: >> On 1/14/2013 8:28 PM, David Bailey wrote: >>> On 14/01/2013 05:01, Richard Fateman wrote: >>> > >> >> The point is that Mathematica is confusing to new users; > > Well I'd imagine that engineers who simply want to perform a > mathematical calculation - one that doesn't come straight out of the > box, like an isolated integral - the Mathematica language is probably > easier to use than LISP. Using Mathematica as a simple command language -- a front end to the symbolic mathematics application program underneath -- is quite different from using Mathematica as a language in which to build significant new applications. Even so, you seem to forget the trouble new users have in typing simple mathematics into Mathematica. The surprise when sin(x)/x turns out to be sin. >>> > >> Maybe it will be in version 10. There is no way of telling from outside >> the company. > Possibly, but on the whole features seem to mature fast and then remain > stable. I am sure that is the intention. >> >>> > >> >> There is an ANSI Standard Common Lisp that has a range of features. >> Arrays were in "early" Lisp at least by 1966. There were arrays in >> Fortran and Algol before that, so Lisp wasn't first. If you want to >> criticize languages by historical relics, you might note that Fortran >> doesn't have subroutines. Oh, variants of Fortran added subroutines. > Clearly people can argue endlessly over the merits of different > languages. To me, the interesting feature of early LISP was the elegant > minimalist design. It seemed to offset my irritation that foo(1,2,3) is > a lot easier to read than (foo,1,2,3) First of all, it would be (foo 1 2 3). No commas. and that the language did live up > to its name: Lots of Irritating Sets of Parentheses! Once it had to add > other constructs that elegance was lost. Any experienced Lisp programmer these days will use an editor that keeps track of both indentation and parentheses, and so the structure of a program will be quite evident from the indentation. A programmer will probably first notice the error in indentation and correct it by adding or removing a parenthesis. It is an enormous boon to the construction of programs with nested structure, such as if-then-else conditionals, and mathematical expressions. In case you hadn't noticed, the parenthesis structure for large deeply nested mathematical expressions is difficult for humans to comprehend accurately; fortunately the INPUT lines in Mathematica are generally short, while the OUTPUTS are the complicated ones. The prefix vs. infix issue is also a red herring. If Lisp programmers wanted to use infix they would use any of a number of free infix front ends. They rarely do. >> >> >> >> Mathematica seems to have kept its original design (at >>> least in this area) over the years, even though internally, lists now >>> come in two flavors! >> >> Mathematica's internal design has apparently changed in many respects; >> some WRI literature claims it's been entirely rewritten. >>> > Well obviously it is only the external design that is directly relevant > to us. Not if the efficiencies change drastically, which they do. I'd expect the internal design to change radically, as for > example, typical available RAM soared during the two decades following 1990. >>> > > >> >> I think the issue is not only that it violates transparency, but that it >> mis-uses terms, it can make a hash of comparing algorithms and data >> structures for efficiency, it is expensive and proprietary, it has no >> formal definition, and some things are done just out-and-out wrong from >> the perspective of computer science and numerical analysis. >> >> But other than that, eh.. > Which kind of makes me wonder why you actually use Mathematica! If you > listed some of the things you like about the system, it might become > apparent that a variety of subtle tradeoffs were necessary to provide > those features. I rarely write programs of any length in Mathematica, because (as I've said) I hold the programming language in generally low regard. On the other hand I am pretty much familiar with the language because I wrote a parser for it (in Lisp) some time ago, and in my experience one of the best ways to really learn a language is to "implement" it. I do find it an object of curiosity to see how some ideas are expressed by the symbolic mathematical routines (e.g. integration). And the Solve (and related, e.g. Reduce) programs have followed an interesting path of improvement. It is also useful for finding high-precision values of numerical library functions to compare to other programs, e.g. Bessel functions, that I was experimenting with. Unfortunately for Mathematica, I found bugs in its Bessel function (reported and acknowledged by them). Here's one in version 8 (I do not yet have version 9 installed) q=429515858585961022071539/6922263581864661506963; a=N[BesselJ[0,q],45]; b=N[BesselJ[0,q],100]; c=N[BesselJ[0,q],45]; a==c returns False. If I were using a computer to do something that required correct answers for, say, life safety, like building a bridge, I would follow WRI's advice and not use Mathematica. (see http://www.wolframalpha.com/termsofuse/)