Re: Mathematica and Lisp
- To: mathgroup at smc.vnet.net
- Subject: [mg129645] Re: Mathematica and Lisp
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Sat, 2 Feb 2013 01:16:47 -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> <kef6pb$k9a$1@smc.vnet.net>
On 1/31/2013 5:46 PM, John Doty wrote:
....
>> (RJF WROTE)
>> 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.
>
>(JD WROTE) That's crazy. Implementing a language teaches you nothing
> about its true strengths and weaknesses. To learn that, you must
>*use* it for real-world problems, not the toy problems of theoretical
> computer science.
You miss the point. Let me try to clarify this. Mathematica consists
of several parts. Among these:
a specialized language and implementation of a graphics package.
an implementation of routines for Solve, Reduce, Eliminate.
an expression "simplifier" e.g. FullSimplify and friends.
an implementation of significance arithmetic (bigfloats).
....
There is also a programming language, which appears to have no separable
name and so it too seems to be called Mathematica. One can imagine
this language stripped of all the application stuff specific to
mathematics. Apparently Stephen Wolfram has thought about how this
could be separately sold, though has refrained, so far as I know,
from actually doing this.
This programming language has features, none of which would be called
theoretical computer science by a computer scientist.
Of these features there are many that the vast majority
of users are either unaware of, or misunderstand. This is
probably typical for programming languages and naive users.
In addition to the mysteries of the math application and its implementation,
some of Mathematica's LANGUAGE features are non-obvious and
the misunderstanding is promoted by overly-simplified "explanations"
in the documentation. In some cases the obvious and plausible
understanding for an expert in programming languages, based on
an understanding of what other languages do, is wrong. Now such an
expert might venture to say that such "features" were bugs and should
be corrected.
But one learns that sometimes putting a hat and a
beard on a bug makes it into a feature.
As an example, compare Module and Block. Do you think you
really understand Hold, Defer, Evaluate, UpSetDelayed? Do
you think that I do, after implementing them? (Actually, I did
not implement Defer, which was introduced in version 5.0)
For purposes of discussion here I would
include in the programming language the surface syntax and internal
representation of programs, the fundamental parts of naming, binding,
function evaluation, matching, and integer arithmetic.
I expect that few programmers, even if they have written pages of code,
understand all the binding rules and evaluation orders for Rules and
Functions and matching and such.
Often it does not matter if you have an unlimited store of different
names, and never use the same name twice. But sometimes it does matter,
and people write to this newsgroup with mysterious code.
>
>
<snip>
RJF reports a bug, in version 8, not version 9.
>>
>> returns False.
>
> (JD writes)
> Discovering and reporting this kind of bug is useful, but you're still in the realm of toy problems.
> Such bugs exist in many useful codes, and are only a minor source of error.
Well, there are 3 ways reading this.
1. You are unlikely to encounter this bug.
or
2. If you encounter this bug, it will bother you only in a
minor way.
or
3. Most programs have bugs and it doesn't matter.
regarding 1. Read about the Therac-25, in which a bad software
design was implemented, It hardly affected anyone who was treated
with that X-ray machine. It only killed 3 people.
regarding 2. Read about how arithmetic failure, specifically
the conversion of a 64-bit floating point quantity to a 16-bit
signed integer caused the crash of an Ariane 5 rocket, losing
$500 million. Fortunately unmanned.
For more examples, see
http://www.ima.umn.edu/~arnold/disasters/disasters.html
regarding 3. Programming languages with mysterious and undocumented
semantics (as well as poor debugging features) are likely to make
validation more difficult than otherwise.
>
> SPICE3 has been around for about a quarter of a century, and has been
>critical to billions of dollars of electronic design efforts.
Nevertheless,
>I found and reported a bug in a SPICE3 variant last week. "All
non-trivial software has bugs".
This does not seem to me to justify either a bad programming language
design or bugs in Mathematica.
SPICE was, incidentally, developed at Berkeley in my department.
>
>> (RJF) 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.
>
> (JD) I use Mathematica in the creation of designs for space flight hardware.
>But, of course, I don't *only* use Mathematica. It's most useful for
exploring
>ideas ahead of detailed analysis with more specialized software.
>But in my business counting on unverified calculation, regardless of
the source,
>is asking for trouble.
If you find Mathematica useful, fine. If you were using it to (for
example) generate code for real-time embedded processors for space
flight controllers, I would hope you would be very aware of the Ariane 5
and similar disasters.
There is, however, an underlying issue here. That is, it is somehow OK
for Mathematica to have bugs because -- its result would be
independently verified, when it matters.
Imagine someone doing some speculative computation in Mathematica, and
exploring some actually non-existent physical phenomenon which was
predicted because of numerical errors.
Perhaps you are familiar with such controversies regarding computer
simulations and Reynold's numbers.
This is not my area of expertise, but is perhaps within yours.
I just googled and found
"Computing high-Reynolds-number turbulence: will simulations ever
replace experiments?"
http://torroja.dmt.upm.es/pubs/2003/jimenez_jot_2003.pdf
This is pretty far afield from the original question which I
think was somehow...s Mathematica somehow Lisp-like.... should I learn Lisp...
Anyone can obviously use whatever tools float your boat/rocket ship.
To make a plausible case that you are using an especially
good "programming language" and should/should not learn another
seems to call for some comparative evaluation from people who
have appropriate expertise (in programming languages).
Unless the original poster was
also in the space-flight business, your opinion may not be
what he is looking for. I don't know for sure what his
field is, but I expect ... It's not rocket science :)
RJF