Re: Comparison between Mathematica and other

*To*: mathgroup at smc.vnet.net*Subject*: [mg92562] Re: Comparison between Mathematica and other*From*: AES <siegman at stanford.edu>*Date*: Sun, 5 Oct 2008 06:06:22 -0400 (EDT)*Organization*: Stanford University*References*: <200809301133.HAA21932@smc.vnet.net> <gc7frc$en0$1@smc.vnet.net>

> > > Transpose[ > > > Sort[Transpose[Eigensystem[RandomReal[{-1, 1}, {6, 6}]]], > > > > > > Re[#2[[1]]] < Re[#1[[1]]] || > > > Re[#2[[1]]] == Re[#1[[1]]] && Im[#2[[1]]] < Im[#1[[1]]] &]] > > > > > > I think this also is a good example of the use of functional programming, > > > and it helped me to get in to it. > > > In Mathematica we are thus able to sort any kind of "objects" with any > > kind > > > of sorting criteria, thanks to the generality of the language. I'm really not attempting to re-open the functional vs procedural programming battle here, but I'd offer a couple or three observations on the above: 1) Commands like Sort[ ], Transpose[ ], Re[ ] are evidently "functions" and I suppose these functions contain massive levels of sophisticated functional programming (and pattern matching) in their internals -- -- but just using them as functions doesn't, it seems to me, really constitute hard-core "functional programming" by those users who do this. Their names are ordinary English or mathematical terms; what they do (or are likely to do) will seem obvious to even the most unsophisticated user; and they can be readily used even by unsophisticated (or entirely procedurally oriented) users, at least in their default modes, without even knowing what functional programming is -- that is, without such users learning (or having to remember) any kind of arcane symbols or functional programming notations or structures, and especially any symbols and notations that are not used in and familiar from, say, elementary algebra or calculus. Just using -- or even defining for yourself -- a named function (macro, subroutine, whatever) doesn't seem to me "functional programming" at any very meaningful level; and doing this certainly doesn't depend on the "generality" of Mathematica as a language. These same capabilities are certainly present, and commonplace, in what I believe are labeled as crudely "procedural languages" (FORTRAN, BASIC, etc). 2) Now it's certainly true that if you want to modify the default behavior of Sort[ ], you do indeed have to be able to do (or more likely copy and modify) what I'd agree is some very modest level of procedural programming, as well illustrated in the example above: Re[#2[[1]]] < Re[#1[[1]]] || Re[#2[[1]]] == Re[#1[[1]]] && Im[#2[[1]]] < Im[#1[[1]]] &]] But even I (a resolutely procedural type) would have little trouble with this particular example, since the level of 'arcanity' is really pretty limited: The "#n" notation for arguments is familiar from TeX (and what other languages?); the "||" and "&&" notations are familiar from low-level logic classes; and the "==" and "[[ ]]" notations are pretty basic Mathematica. The only 'arcane' thing (for me) is the single "&" at the end, which I have no idea why is there, but I'll dutifully copy it. 3) As a fallout from this, I'll continue to argue that if Mathematica really wants to expand and serve the widest possible customer base -- e.g., high school math and physics students, college students (and grad students) in nontechnical fields, working engineers in industry, etc. -- for those audiences (aka customers) it should: 1) Substantially sharpen its focus on making and keeping Mathematica simpler and easier to use and much easier to learn for those audiences, including a focus on better documentation and fewer complexities and "gotchas" (which is not imply taking away any of the pattern matching and functional programming underpinnings that are so crucial to other, more sophisticated users of Mathematica); and 1) Drastically reduce its prices. --AES, Oct 2008

**Follow-Ups**:**Re: Re: Comparison between Mathematica and other***From:*Murray Eisenberg <murray@math.umass.edu>

**an interesting problem of supplying boundary condition for a PDE**

**Re: fellow authors**

**RE: RE: Comparison between Mathematica and other**

**Re: Re: Comparison between Mathematica and other**