Re: Mathematica daily WTF
- To: mathgroup at smc.vnet.net
- Subject: [mg115135] Re: Mathematica daily WTF
- From: Richard Fateman <fateman at eecs.berkeley.edu>
- Date: Sat, 1 Jan 2011 04:26:42 -0500 (EST)
- References: <ifj6n0$594$1@smc.vnet.net> <4D1E0675.6050306@cs.berkeley.edu> <7C1C80B9-7425-427A-B8C3-7DA946B6283F@mimuw.edu.pl>
On 12/31/2010 9:25 AM, Andrzej Kozlowski wrote:
>
>> --- I do not hold this view, and I wonder how you came to believe
>> --- I hold this view.
> OK, perhaps I misunderstood you. I was referring to something you once wrote to me, which could have however referred to a dislike of how procedural programming is implemented in Mathematica:
>> When using the "procedural" parts, I find strange things happen. Then
>> I recall that it is really doing pattern matching, and f[x_]:= .. is
>> a rule.
I don't recall the exact context, but I suspect that it is something
like this:
I think that if my program contains f[123] , that the function f
is called on the argument
123. Not so. First, 123 must be successfully matched against the
argument list.
Otherwise the value is simply f[123]. Not, say, "error, wrong argument
to f".
> anyway, it does not matter as far as the point I was making is concerned, which is that the C-like structure of Mathematica procedural programs is helpful to people (somewhat) familiar with C or Fortran.
>
Except that it isn't, unless all your pseudo-procedures have only "_"
arguments,
e.g. f[x_,y_,z_]:=
and if you always have the exact number of arguments correct.
>> While this
>> certainly would be offensive to the aesthetics of a pure functional
>> language like Lisp (or better Scheme),
>>
>> --- Lisp is certainly not a pure functional language. In fact it has
>> --- a construct called loop. Scheme is not a pure functional language
>> --- either. It supports imperative state-based programming.
> Well, anything which allows you to program by "side effects" is supports imperative programming.
You really are convinced that Lisp is something alien. While it is not
required that a user write programs this way, here is a Lisp program
(defun andrzej (x)
(prog ()
(print x)
(go label3)
(print 2)
label3
(dotimes (i 5)
(print i))
(return 7)))
You can probably guess what it does.
> It does not mean it is considered "good style" to program in this way.
The only side effects in this program are output. To a large extent it
is possible to write
programs in C (etc) in a functional style, so the choice of style is not
necessarily
dictated by the language. Though some languages are more constrained.
> O.K., I should have written Haskell. Would not have made any difference to my argument.
>> While Mathematica's
>> procedural programming is usually unattractive and often inefficient,
>>
>> --- Huh? I don't understand why you think M's procedural
>> --- programming is (especially?) unattractive. Or inefficient.
>> --- Perhaps you mean its implementation is inefficient? This
>> --- has to do with the difficulty of compiling it, so it
>> --- is partly a language issue. It could be partly overcome
>> --- by adding (optional) type declarations as in lisp.
>
> I wonder whether you are really incapable of understanding what
>> to everyone else is obvious or just pretend to do so.
>
>> (I suspect its the latter and that for some reason you find this amusing).
>
>> Obviously my meaning was that in Mathematica in most cases a procedural
>
>> program can be replaced by a more compact and, to most people, more elegant looking, "functional" one.
>
I think that you are trying to make a distinction between, say,
Map over a list L by
Map[f,L]
instead of something that accesses each element of L, e.g.
Table[f[L[[i]]], {i,1,Length[L]}]
Calling this functional vs. procedural is not the important
distinction. It is using implicit iterators over compound
structures to decrease the burden on the user-language
implementation. Presumably "Map" knows better how
to access sequentially all the elements in a list.
> Of course we know that generally they are both something else, but
> the latter kind tend to be more elegant and more efficient
> (without compiling, of course, which can't be used for programs
> that perform symbolic computation - an obvious thing that somehow you decided to forget).
It is certainly possible to compile programs that perform symbolic
computation. Lisp does it all the time. It helps to declare types,
so that specialized code can be used.
>> there are plenty of users who will not use anything else
>> (including one user who frequently takes similar positions
>> to yours on various Mathematica related issues) and would
>> not even consider a alternative program that used Lisp
>> for programming - just for that very reason.
>>
>> --- Lisp supports essentially any
>> --- programming "paradigm" that anyone has come up with,
>> --- functional, state-based, rule-based, object-oriented,
>> --- constraint-based, graphical, etc.
>> --- I assume the person referred to above, talking about Lisp
>> --- does not know that much about Lisp.
> The user in question obviously does not know Lisp and I sure would not spend any time to try to learn it.
>
>>> What I referred to as a matter of "convenient syntax"
>> is actually a quite crucial issue, for most people easily
>> overriding in importance anything else mentioned in this thread.
>>
>> --- Huh? You said M's programming is unattractive. Are you
>> --- saying that Function[{x},N[x^x]] just will not do, and
>> --- users crucially need the convenient syntax (#^#//N)& instead?
>>
> I said nothing of the sort. What on earth makes you think I did?
I don't know what you mean by convenient syntax, then. Is Mathematica's
syntax more convenient than any other CAS?