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 experience: > 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 > between. 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. And finally: > 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 http://support.wolfram.com/mathematica/interface/typesetting/stringcorruption.html 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. Dave Withoff Wolfram Research