Mathematica is a powerful computational engine, and I do all my research and some of my teaching using it. Cosma Shalizi has posted his thoughts on programming well in R, and Martin at Geary has posted his thoughts and some cool links on Stata, so I thought I'd write something about Mathematica, rather than ranting about the Irish economy for a while. There are much more qualified people than me doing that anyway.
First thing you should know is I taught Mathematica for economists a few years ago, and the course files are located here. Check them out and give me some feedback if you like them.
Second thing you should know is I'm not an expert, though I have taken classes from Wolfram research on using Mathematica to program. Details of those are here. I'm just barely qualified to use it for my own ends. I'm going to assume you've never taken a programming class, as with most social scientists. But in spite of all those caveats, I've got some tips for you, and in time-honoured bloggy fashion, I've made a list.
- Don't jump right in. Write down what you want to do on a piece of paper before going anywhere near a computer. Jumping straight into coding is a mistake. It's better to think carefully about what you want the code to do before coming up with the code itself. Begin by asking what you want to do. Then ask how Mathematica can do that. Then search the help browser for commands and syntax to help you do that.
- Code small. When you know what you want to do, code in tiny functions which do one thing, then splice those functions together. Don't iterate too much throughout, or you'll really slow your program down. Write comments in (* *) like this to yourself throughout the code. You'll want to do this, because right after staying up all night to finish the first draft of the code through bleeding eyeballs, you're going to...
- Bin the first draft. When you've written the first draft, and you're sure it works, throw it away. Then cry. Then get back to work.
- No, really. Chuck it. The first draft of the code will take, say, 30% of your time in coding, because you are really trying to find the language to ask Mathematica to perform some computation for you. The second draft will take 10% of the time it took you to write the first draft, and you'll write a better, more compact, and more efficient program. Honestly. It will save more time in the long run.
- Write tests. Write tests for accuracy in the program. Within Mathematica, there are many simple checks you can make to ensure the program is doing what you think it might be doing, so use them, or write your own. My favourite is MaxPrecision.
- Graph stuff. Mathematica (especially version 7) has extensive statistical and graphing capabilities, so use them to get a handle on what it is your program is doing, and what kind of outputs you can expect. Chances are you're using Mathematica to produce graphs anyway, so just build these into the program (Module) as outputs to separate files. It's a great way to produce results you can compare in different runs, especially when you simulate.
- Ask people things. Check the help browser and the net, and if you get really stuck, join the Mathematica group, and ask a question. Most people (I say most, not all) are very helpful, and will get back to you in a week or so.
- Read books. Here are my favourites: "Programming in Mathematica (3rd Edition)" (Roman Maeder), "Mathematical Statistics with MATHEMATICA" (Colin Rose, Murray D. Smith) and "An Introduction to Programming with Mathematica, Third Edition" (Paul R. Wellin, Richard J. Gaylord, Samuel N. Kamin)
That's it, any more hints, tips, etc, leave in comments, email me, or if I think of them, I'll post them.