MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: an interesting problem of supplying boundary condition for a PDE
  • Next by Date: Re: fellow authors
  • Previous by thread: RE: RE: Comparison between Mathematica and other
  • Next by thread: Re: Re: Comparison between Mathematica and other