Re: Re: Front end problems!
- To: mathgroup at smc.vnet.net
- Subject: [mg32207] Re: [mg32176] Re: Front end problems!
- From: David Withoff <withoff at wolfram.com>
- Date: Sat, 5 Jan 2002 00:11:06 -0500 (EST)
- Sender: owner-wri-mathgroup at wolfram.com
I am sorry if you have had difficulty with unexpected syntax errors
in typeset input, and in particular if anyone from Wolfram Research
ever said or implied any of the things that you quoted regarding
these problems. For example, the "yeah, we know..." quote in
> These bugs have been in Mathemathica front end as long as I remember. I have
> reported them to WRI with short explicit repeatable examples. Basically the
> answer was "yeah, we know, but Mathematica handling of carriage returns and
> newlines and spaces and comments etc. is so complex and delicate, that we
> really are not sure how to deal with it".
is certainly not correct, and I aplogize if anyone from Wolfram Research
ever said such a thing. The handling of all of these things is essentially
obvious, and any departure from that handling is a bug. I am sorry if anyone
ever said otherwise. The only partial exception is handling of carriage
returns, where there is the fundamental ambiguity associated with the fact
that a carriage return can indicate either multiplication or a separation
between complete expressions, but the examples here don't seem to involve
that ambiguity, so they are probably all just demonstrations of a bug.
In passing I might mention that the following does not match with my
> I was always puzzled how people apparently manage to use Mathematica without
> having constant problems with unexpected syntax errors. I came to the
> conclusion that a huge majority use Mathematica interactively and only
> create small cells with relatively short and few expressions that don't
> extend over more than one line and don't need any white space or comments in
Although I don't want to downplay the seriousness of this bug, and would
certainly agree that it can be very troublesome if you encounter it, I've
also seen thousands of people write immense Mathematica programs without
ever encountering this problem, and most of those who have found it
report it as nothing more than a minor incident. To put it another way,
there are a lot of other issues (speed, memory, etc.) that come up much
more frequently and that are much more dominant considerations for most
people who want to write large programs in Mathematica.
> Also a long time ago I tried to suggest to WRI compiling a bug list but they
> said 'NO'. They said it is impossible to create a bug list for Mathematica,
> because Mathematica is the one , uniquely complex piece of software with
> which such a crude and mundane concept as a bug list is not compatible,
> would not work and just cannot be done. One can make bug lists for this or
> that trivial software, but not for Mathematica.
anyone who said any of that was very mistaken -- and again I apologize if
anyone from Wolfram Research ever said or implied any of it. Everything in
that quote is wrong, from beginning to end.
For one thing, there already is a bug list, and there has been for a long
time. It is in the Wolfram Research web site (http://support.wolfram.com).
For example, the following page
describes a bug which is closely related to the bug being discussed here.
There is also nothing unique about the difficulties of creating a bug list
for Mathematica. The same difficulties come up for almost any software.
These difficulties have been extensively discussed, including several
essays that have been posted over the years in this newsgroup. It is
a very difficult problem.
I don't want to review all of those difficulties here, but one of the
more obvious difficulties is that writing useful documentation for bugs
is much harder than writing useful documentation for intended behaviors.
With intended behaviors, you have a pretty good idea of what you are
documenting, and those behaviors follow a logical pattern. With bugs
you usually have only a very vague idea of what you are documenting,
and the corresponding behaviors tend to defy organization.
It is also worth keeping in mind that just as there are bugs and omissions
in software, so also there will be bugs and omissions in any bug list.
In fact, usually there are far more bugs in the bug list, since the bug
list is harder to create, and gets a lot less use.
There are about a zillion other considerations, and if I seem a big
impatient it may be because I'm pretty sure I've seen all of them quite
a few times. You are of course welcome to challenge that. If you or
anyone thinks they have any special insights on a practical way to set
up a more useful bug list than we've already got, you could bring them
up here, or send your suggestions to technical support.
Prev by Date:
Re: Front end problems!
Next by Date:
Wrestling with Mathematica on Trig Simplification
Previous by thread:
Re: Front end problems!
Next by thread:
Revolving a Rectangle About an Axis