1. ** Programming is fast. **Especially for smaller simulations, I find that I can solve a given problem using *Mathematica* in one half to one tenth of the time it would take me to solve it using Pascal, my previous language of choice. There are a number of reasons for this, many of which will become apparent in the course of this tutorial.

2. ** Output is pretty. **As you will already know if you've played around with the graphics routines provided in *Mathematica*, it is easy to generate all sorts of fancy customized representations of your data, from contour plots to pie charts to three-dimensional surfaces. Unfortunately, getting these fancy representations up to publication quality is not so easy - but I cover those issues in a separate tutorial.

3. ** Code is elegant. **Once you get the hang of using *Mathematica* as it was designed to be used, instead of as a poor substitute for a procedural language like C or Pascal, I suspect you find that your code is extremely elegant. For many kinds of problems, a simulation written properly in *Mathematica* will be less than a tenth as long as the equivalent written in Pascal, and far easier to understand at a glance.

4. **Programs are easy to debug. **This one you'll just have to see you for yourself. I personally find that in *Mathematica* programs it is maybe a tiny bit harder to fix syntax errors, but it is far easier to find logical errors. Using *Mathematica*, it is easier to independently test each component of the program to make sure it is functioning as you intend. And this worth a lot - I have never worried that I might be about to publish results based on a simulation with syntax errors, after all. I wish I could say the same of logical errors.

5. **Programs mirror the processes that they simulate.*** ** *I find that *Mathematica* simulations more closely mirror the actual mathematical structure of the processes that they are designed to simulate. This makes it easier to catch logical errors (as mentioned above), and also can really help you understand the nature of the system with which you are working.

6. **Data is easily displayed in multiple forms.** When programming in C or Pascal, I sometimes want to see my data summarized in a different format, but often it's pain to actually do so, and I decide not to bother. This can be a real loss, because sometimes by switching perspective on the data one can see entirely new aspects of the system being studied. In *Mathematica*, I find it very easy to look at the data in multiple ways. This holds for a number of reasons; among them is the ease with which *Mathematica* manipulates lists and multidimensional arrays and extracts data from them, the ease with which various graphical summaries can be produced, and the general trend in *Mathematica* programming of storing al the data generated in the simulation and only after the fact summarizing the results via various measures (this approach is treated in detail below).

1. **Computational speed is slow. **I have not done the benchmarks
myself, but *Mathematica* is clearly not as quick as C for doing many
computationally-intensive tasks. If you have a really big simulation that is
going to take days to weeks to run, people claim that you can get up to
hundred-fold increases in speed by programming in tight efficient C.

2. **Syntax can be difficult. **There is definately a learning
curve where syntax is concerned. *Mathematica* syntax can seem rigid
(though almost always for very good reason, once you understand why things
work as they do). Moreover the error messages can be extremely confusing.
Often a program or a line of code will not work, and the associated error
message will give you almost no clue what could be going wrong. You get over
this, in time. One learns how to interpret the error messages that once
seemed cryptic, and quickly find any problems. Moreover, any difficulties in
finding and fixing syntax errors are more than compensated for by the
improvements in finding and fixing logical errors, in my experience.

3.** User interface programming seems tricky. **Writing programs
with bulletproof user interfaces - particularly for end-users with no
*Mathematica* background - seems difficult. I honestly don't have
enough experience with this to be certain one way or the other. Perhaps
further experience, or experience with *Mathematica*
*4.0* will change my mind here.

4.
*Mathematica*** is proprietary software. **Even worse than
that, it is protected by an absurdly complicated, rarely functional, and
hopelessly frustrating on-line registration and password scheme that - in my personal experience -
usually imposes at least a day's
wait between installing and actually using the program. I would imagine that
the hassles involved would drive away ten paying customers for every pirate that
they deter**. **It's a *very useful* piece of proprietary software,
and no comparable GPL alternative is available, but it is still proprietary,
and the licensing system seems to me to exemplify the very worst characteristics
of proprietary software.

Converted by