Re: Mathematica and Lisp
- To: mathgroup at smc.vnet.net
- Subject: [mg129727] Re: Mathematica and Lisp
- From: John Doty <noqsiaerospace at gmail.com>
- Date: Fri, 8 Feb 2013 05:11:58 -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>
On Wednesday, February 6, 2013 9:28:00 PM UTC-5, Richard Fateman wrote: > I personally find the debugging facilities in Mathematica to be quite > > difficult to use. I personally don't use them, but I personally find Mathematica programs easy to debug. > I speculate that it is because the "working model" > > I have in my mind (and I suspect others share it) is that I am writing > > programs, composing them in various ways. In reality, the internal > > evaluation strategy of Mathematica is to apply rules to transform > > expressions. So while I'm looking for a clue as to which "program" > > has the bug, the debugging info shows transformations of expressions. Yes! Now, we're getting someplace. > > This jerking back into the reality of Mathematica's actual nature > > of evaluation generally prompts me to shy away from the use of Trace. If you're using Mathematica, why ever leave that reality? Why not stay in it and use its power? If that's not working for you, why use Mathematica in the first place? > > I don't know if it is inevitable, but Trace in particular, and debugging > > in general in Mathematica seem to me to be quite weak. Trying to figure out what Mathematica's doing using Trace[] is like trying to figure out what a 1960's mainframe was doing from the blinking lights on the console. Useful in special circumstances, but too much detail in general. > To the > > extent that some people might like Mathematica for debugging, it may be > > that they are comparing it to a non-interactive system (like batch > > FORTRAN) which will crash and print out a hexadecimal core dump. Not really. Where Mathematica shines is test-driven development. Whenever you complete a definition, try it on a test case or a few. That finds most bugs quickly, and it also encourages good factoring. That good factoring helps out later when you discover a bug has slipped through, making it easy to isolate the definition responsible. > There is a profiler in the Mathematica Workbench. I have not tried > > to use it but from the documentation it seems to suffer from the same > > viewpoint as Trace. It also requires running Mathematica in "debug" > > mode; I don't know how that affects timings. When I reach the point where I care enough about timing of numerical code that judicious use of Timing[] isn't providing enough insight, I generally declare the Mathematica code to be a finished prototype and move on to a more suitable language for production code. > So in regard to item 5, nearly any alternative system that has an > > appealing debugging framework. Which would be almost anything that > > is not bound up in the rule-based paradigm of Mathematica. But the rule-based paradigm is fundamental here. Formal proof in mathematics is rule-based. Mathematica implements a formalist vision of mathematics filtered through a physicist's pragmatism. That's why it's so good at mathematics, especially the applied mathematics of science and engineering. In Mathematica, programming is secondary: partly emergent and partly added on. If programming is your primary focus, Mathematica should probably not be your language of choice.